שלום.
אני משתמש די מנוסה בלינוקס לגרסאותיו (הכל יחסי).
עשיתי חיפוש ולא מצאתי תשובה לבעיה שלי, והיא:

יש לי שרת עם לוח של אינטל 5000 (ספלו) עם HOT SWAP.
מוגדר עליו MIRROR RAID חומרה.

הבעיה היא כזאת.
DEBIAN לא מזהה את ה-RAID, או יותר נכון מתעלם ממנו (מזהה 2 כוננים בשלב ההתקנה).
FEDORA מזהה RAID (ז"א רק כונן אחד, כמו שצריך), אבל לא כ-SDA (לא ממש מפריע לי, אבל...).

אחרי שעברנו את זה (והתקנתי FC6), משום מה ה-HOT SWAP לא "שקוף" למערכת הפעלה.
כל פעם שאני שולף דיסק, היא מזהה את זה.
בנוסף יש לי חשד יותר מסביר שהיא לא מבצעת סינכרון בין הדיסקים, אחרי ששולפים אחד ומכניסים אותו שוב מאוחר יותר.

יש לי ניסיון עם שרתים של HP (גירסאות G3/4/5 למיניהן) ושם הכל עובד חלק ושקוף.
יש למישהו מושג?


** הערה קטנה, אם יש פיתרון לעניין של DEBIAN, אני אשמח, מעדיף אותה.
** יש גירסה דומה ל-NETINSTALL של DEBIAN, אצל FEDORA?

נשמע לי שאין לך RAID חומרה בשרת, אלא RAID מזוייף שמי שבפועל עושה את ה RAID הוא מערכת ההפעלה ולא בקר ייעודי.

אין קשר בין HOT SWAP ל RAID חומרה או לא - זה סתם היכולת האלקטרונית להיות מסוגל לנתק ולחבר כוננים בלי לשרוף שום דבר

כנראה של"רייד" הזה יש דרייבר ללינוקס שמלמד את הקרנל לדבר עם ה"ביוס" של ה"בקר" ולמשוך ממנו את המידע על טופולוגיית הדיסקים - וכנראה שבפדורה הדרייבר הזה קיים (כיוון שלדביאן יש תחביב להיות עתיקים; ממליץ לך להפטר מהפצה זו ) - ובדביאן לא.

יש בתגובה שלי הרבה "כנראה", בגלל שאת הנתון שהכי מעניין אותי לא אמרת - איך הפדורה קורא לכונן אם לא sda (כנראה בשם של הבקר. כמו שב HP , לפחות טרום עידן SAS, יש למשל את dev/cciss/c0d0/)

אם אני אכן צודק, אזי - לדעתי - חבל על בזבוז הזמן - הדרייברים והבקרים המזוייפים בדר"כ יעשו עבודה פחות טובה מאשר רייד התוכנה המובנה של לינוקס (MD) (ע"ע Linux Software-RAID HOWTO).

אם אני אכן צודק, זה יסביר למה כשאתה משחק עם הדיסקים, מערכת ההפעלה בכלל רואה את זה. כי היא מנהלת את זה, ולא BIOS ייעודי של בקר RAID (במקרים האלה צריך לעשות query עליו באמצעות תוכנות שירות ייעודיות, כידוע).

תגיד לי אם זה נשמע לך הגיוני

נמאס לכם לזכור סיסמאות? לחצו כאן!

א. תודה על התשובה.
ב. הלוח אכן עם רייד חומרה, זה הדגם - Intel® Server Board S5000VSA

אין בעיה לעשות REBUILD וכו' דרך הביוס ולא דרך המערכת הפעלה.
הדגשתי את ה-H/S בשביל הבעיה שאני נתקל בה (סינכרון דיסקים כשהמערכת "למעלה").
מבחינת חומרה ברור לי ההבדל

אני אנסה לבדוק איך FEDORA מזהה את הכונן, עברו כמה שבועות טובים מאז ההתקנה.
מה שכן, זכור לי שזה לא בשם הבקר אלא MAPPER או משהו בסגנון אם אני לא טועה (במקום SDA) וכו'.
מחר על הבוקר אוודא.

חלק מההערות שהוא רושם ב-LOGS
scsi 0:0:0:0: rejecting I/O to dead device
error on device sda1, logical block 1
lost page write due to I/O error on sda1

ברור לי שמשהו לא הגיוני.
מבחינתו הכונן מת לאחר שהוא הוצא והוא לא מזהה הכנסה שלו.
כל עוד לא מוצא הכונן, הרייד עובד תקין, לאחר שהוא מוצא ומוכנס שוב, הוא כבר לא מסונכרן יותר.
הרייד עובר ל-degraded, ואז צריך לסנכרן את הכוננים דרך הביוס.

אם ידוע על קטץ' מסוים עם הבורדים האלה, אשמח לדעת.
משהו לא מסתדר לי כאן, ויש לי מעט ניסיון עם שרתים ומערכות הפעלה.

בכל מקרה, מה שכתבת נשמע הגיוני, חשבתי על זה, אבל ב-DATASHEET של הבורד רשום במפורש שיש רייד 0,1.
הזוי.

ב. איפה כתוב בדף הזה שה RAID הוא חומרה? גם בלוח האם הביתי שלי יש "רייד" 0/1 (טיפ: בד"כ בקר רייד אמיתי יתמוך ב RAID5....)... חפש ברשת על "fakeraid" ותגלה איך נראית תרמית של יצרני לוחות אם...

mapper לא קשור לבקר עכשיו אני מבין... mapper הינו הממפה של מערכת LVM (שזה Logical Volume Manager) - טכניקה לבצע חלוקה דינאמית של מחיצות שרצה מתוך מחיצה פיזית אחת, ומאפשרת שינוי גודל (הקטנה והגדלה) בזמן שהמערכת רצה. ה LVM עצמו רץ בתוך מחיצה אחרת. תסתכל על הפלט של הפקודות pvs ו lvs...

דוגמא משרת HP שלי שהתקנתי עליו LVM ידנית ע"ג ג'נטו:

קוד:

# fdisk -l

Disk /dev/cciss/c0d0: 299.9 GB, 299992412160 bytes
255 heads, 63 sectors/track, 36472 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

           Device Boot      Start         End      Blocks   Id  System
/dev/cciss/c0d0p1               1          32      257008+  83  Linux
/dev/cciss/c0d0p2              33       36472   292704300   8e  Linux LVM

# pvs
  PV                VG   Fmt  Attr PSize   PFree
  /dev/cciss/c0d0p2 vg   lvm2 a-   279.14G 38.89G

# ls -l /dev/mapper/
total 0
crw-rw---- 1 root root  10, 63 Oct  3 09:47 control
brw------- 1 root root 254,  5 Oct  3 09:47 vg-home
brw------- 1 root root 254,  6 Oct  3 09:47 vg-logs
brw------- 1 root root 254,  4 Oct  3 09:47 vg-root
brw------- 1 root root 254,  3 Oct  3 09:47 vg-swap
brw------- 1 root root 254,  2 Oct  3 09:47 vg-tmp
brw------- 1 root root 254,  0 Oct  3 09:47 vg-usr
brw------- 1 root root 254,  1 Oct  3 09:47 vg-var

# lvs
  LV        VG   Attr   LSize   Origin Snap%  Move Log Copy%
  home      vg   -wi-a-  90.00G
  logs      vg   -wi-a-  50.00G
  root      vg   -wi-ao   3.00G
  swap      vg   -wi-ao   2.00G
  tmp       vg   -wi-ao 256.00M
  usr       vg   -wi-ao  10.00G
  var       vg   -wi-ao  10.00G

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg-root   3.0G  2.0G  1.1G  67% /
udev                  1.8G  552K  1.8G   1% /dev
/dev/mapper/vg-tmp    256M   33M  224M  13% /tmp
/dev/mapper/vg-usr     10G  4.9G  5.2G  49% /usr
/dev/mapper/vg-var     10G  3.6G  6.5G  36% /var

החבר'ה של רדהט משתדלים לדחוף את LVM לכל ההתקנות שלהם בברירת מחדל, בלי ממש לשאול אותך אם אתה מעוניין בזה. אמנם זה נוח מאוד [אם כי, לא כל כך במערכות הקבצים שהם תומכים בהם, שדורשות ממילא השבתה של השרת כדי לשנות גודל של מערכת קבצים], אבל זה פוגע בביצועים (עוד שכבה לוגית...) - ואני הייתי מצפה שיישאלו אותי אם אני מעוניין או לא.

הייתי אומר שזה הגיוני שהוא יחסום I/O על התקן שמת - בייחוד אם הוא חלק מ RAID תוכנה (אם הוא היה רואה את זה כ RAID חומרה והיה רק דיסק אחד, ובכן, זה דומה להוצאת כל הדיסקים מהמחשב, סביר להניח שהמערכת הייתה קופאת בקריאה לפונקציית ה I/O הבאה...) - אם זה היה RAID חומרה, מערכת ההפעלה בכלל לא אמורה להיות מודעת שקרה משהו - מבחינתה הרי יש רק דיסק אחד, איך תהיה עליו שגיאה והמערכת תמשיך לעבוד?

גם הגיוני שאחרי degradation ה RAID לא ישתחזר לבד כיוון שלא ה BIOS מנהל אותו (כמו שאמרתי) - אלא מערכת ההפעלה לוקחת את התפקיד הזה עם הדרייבר שלה (כשהוא קיים. אם הוא לא, זה נראה כמו JBOD...) וכנראה שאתה צריך באמצעות התוכנה להגיד לו שהחלפת דיסק ואתה מעוניין בשחזור (כמו כל RAID תוכנה...)

נמאס לכם לזכור סיסמאות? לחצו כאן!