Archive for the Category » מערכות קבצים «

יום ראשון, אוגוסט 4, 2013 | Author:

I had a power outage affect my server’s large MD RAID array. Rather than let the server as a whole be down while waiting for it to complete an fsck, I had it boot without the large array so I could run the fsck manually.

אולם, when running it manually I realised I had no way of knowing how far it was and how long it would take to complete. This is especially problematic with such a large array. With a little searching I found the tip of adding the -C parameter when calling fsck. I couldn’t find this in the documentation however: fsckhelp showed no such option.

The option turns out to be ext4-specific, and thus shows a perfectly functional progress bar with a percentage indicator. To find the information, instead offsckhelp” או “man fsck”, you have to inputfsck.ext4help” או “man fsck.ext4”. 🙂

לחלוק
יום ראשון, אוגוסט 4, 2013 | Author:

ההיסטוריה

הרבה השתנה מאז שציינתי האחרון שלי שרת אישי – הוא גדל בקפיצות (עכשיו יש לו 7TB MD RAID6) וזה כבר היה לאחרונה מחדש עם אובונטו שרת.

קשת אף פעם לא הייתה טעות. Arch Linux כבר לימד אותי כל כך הרבה על לינוקס (וימשיך לעשות זאת בשולחן העבודה השני שלי). אבל קשת בהחלט דורשת יותר זמן ותשומת לב ממה שאני הייתי רוצה לבלות בשרת. באופן אידיאלי הייתי מעדיף להיות מסוגל לשכוח את השרת לזמן מה עד שתזכורת בדוא"ל, אומר “אום … יש כמה עדכונים אתה צריך להסתכל על, באדי.”

החלל הוא לא בחינם – וגם הוא חלל

ההזדמנות לעבור לאובונטו הייתה העובדה שהייתה לי נגמר SATA יציאות, היציאות הנדרשות לחיבור כוננים קשיחים לשאר המחשב – כי מערך RAID 7TB משתמש הרבה יציאות! אני אפילו נתתי לי משם מאוד דיסק קשיח 200GB ישן כפי שהוא לקח את אחת מהיציאות האלה. אני גם הזהרתי שנמען של הדיסק SMART הניטור הצביע עליו היה לא אמין. כפתרון זמני למחסור ביציאות SATA, אני אפילו נדדתי מערכת ההפעלה של השרת לסדרה של ארבעה מקלות USB בMD RAID1. משוגע. אני יודע. אני לא הייתי מאושר במיוחד ממהירות. החלטתי לצאת ולקנות כונן קשיח חדש ואמין כרטיס הרחבה מסוג SATA ללכת עם זה.

מחיצת הקשת העיקרית של השרת הייתי משתמשת על 7GB של דיסק. נתח גדול של שהיה להחליף קובץ, נתוני מטמון וקבצים אחרים שונים או מיותר. בסך הכל בגודל האמיתי של מערכת ההפעלה, כולל /הבית אוגדן, היה רק ​​על 2GB. זה גרם לי להסתכל לתוך סופר מהיר SSD לנהוג, חשבתי אולי אחד קטן לא יכול להיות כל כך יקר. התברר כי כונן SSD שאינו הזול ביותר שיכולתי למצוא דווקא יעלה יותר מאחד מכונני SSD הקטנים יחסית אלה. Yay עבורי. 🙂

בחירה? Woah?!

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

ההחלטה הבאה הייתי צריך לעשות לא עלתה בדעתי עד המצאות בכל מקום (אשף ההתקנה של אובונטו) בקש אותו ממני: כיצד להגדיר את מחיצות.

הייתי חדש לשימוש בכונני SSD ב-Linux – אני מודע היטב לחסרונות של שימוש לא נכון בם, בעיקר בשל הסיכון של אריכות ימים הגרועה שלהם, אם נעשה שימוש לרעה.

אני לא רוצה להשתמש במחיצת swap ייעודית. אני מתכנן על שדרוג הלוח האם / המעבד / זיכרון של השרת לא רחוק מדי בעתיד. בהתבסס על כך החלטתי שאני אשים swap לקובץ דפדוף RAID md הקיים. ההחלפה לא תהיה מהירה במיוחד, אבל המטרה היחידה שלו תהיה שלאירוע נדיר כשמשהו השתבש והזיכרון אינו זמין.

זה אז עזב אותי כדי לתת לי נתיב שורש 60GB המלא מתוך אינטל 330 SSD. אני נחשב הפרדה / בית אבל זה פשוט נראה לי קצת חסר טעם, ניתן כמה מעט הייתה בשימוש בעבר. אני ראשון להגדיר את המחיצה עם LVM – משהו שאני כבר עושה לאחרונה בכל פעם שאני מגדיר את תיבת לינוקס (ממש, אין שום תירוץ שלא להשתמש LVM). כשזה הגיע לחלק שבו הייתי להגדיר את מערכת קבצים, אני לוחץ נפתח ואינסטינקטיבי נבחרתי ext4. ואז שם לב btrfs באותה הרשימה. תחזיק חזק!!

אבל מה?

Btrfs (“חמאה-EFF-ESS”, “טוב יותר-EFF-ESS”, “דבורת עץ-EFF-ESS”, או כל מה שעולה ביום) הוא יחסית מערכת קבצים חדשה שפותחה על מנת להביא לינוקס’ יכולות מערכת קבצים בחזרה על מסלול עם מערכת הקבצים טק הנוכחי. המלך-of-the-Hill, קיים מערכת קבצים, “שלוחה” (הגרסה הנוכחית נקראת ext4) הוא די טוב – אבל זה מוגבל, תקוע בפרדיגמה ישנה (חושב על מותג חדש F22 ראפטור לעומת. an F4 פנטום עם ניסיון חצי התבדח בשדרוג שקילות) ולא סביר שיהיה מסוגל להתחרות לאורך זמן עם מערכות קבצים ארגוניים חדשים יותר כגון ZFS של אורקל. Btrfs עדיין יש עוד דרך ארוכה לעבור ועדיין נחשבת הניסיון (תלוי את מי שואל ומה תכונות שאתה צריך). רבים מחשיבים אותה להיות יציב לשימוש בסיסי – אבל אף אחד לא הולך לעשות שום ערבויות. ו -, כמובן, כולם אומרים לעשות ובדוק את גיבויים!

Mooooooo

ההבדל המהותי ביותר בין השלוחה וbtrfs הוא שbtrfs הוא “פרה” או “העתק בכתיבה” מערכת קבצים. משמעות הדבר הוא כי נתונים הם לא ממש במכוון מוחלפים על ידי internals של מערכות הקבצים. אם אתה כותב לשינוי קובץ, btrfs יכתוב את השינויים שלך למיקום חדש על מדיה פיזית ויעדכן את המצביעים הפנימיים להתייחס למיקום החדש. Btrfs הולך צעד נוסף שבאותם מצביעים הפנימיים (מכונה מטה) הם גם פרה. גרסות ישנות יותר של שלוחה היו פשוט נדרסו הנתונים. Ext4 ישתמש ביומן כדי להבטיח שהשחיתות לא תתרחש צריך את תקע החשמל יהיה שלף ברגע מאוד לא המוצלח. תוצאות העת במספר דומה של צעדים הנדרשות לעדכון נתונים. עם SSD, החומרה הבסיסית פועלת תהליך פרה דומה לא משנה מה אתה משתמש במערכת קבצים. זאת משום שכונני SSD לא ממש יכולים להחליף נתונים – הם צריכים להעתיק את הנתונים (עם השינויים שלך) למיקום חדש ולאחר מכן למחוק את הבלוק הישן לחלוטין. אופטימיזציה בתחום זה היא שSSD אולי אפילו לא למחוק את הבלוק הישן אלא פשוט רשום למחוק את הבלוק במועד מאוחר יותר, כאשר הדברים אינם כל כך עסוקים. התוצאה הסופית היא שכונני SSD יתאימו היטב עם מערכת קבצים פרה ולא לבצע, כמו גם עם מערכות קבצים שאינם פרה.

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

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

חבר חדש

עם מעל במוח, במיוחד כפי שאובונטו עשה btrfs זמין כאפשרות התקנה בזמן, תארתי לעצמי שזה יהיה זמן טוב לצלול לתוך btrfs ולחקור קצת. 🙂

חלק 2 בקרוב …

לחלוק