שאלת ראיון למומחה שרתי Linux: הדיסק מלא לפי df ו־du מוצא רק חצי. איפה המקום?

אתם בראיון לתפקיד מומחה שרתי Linux. עברתם את השאלות על הרשאות, על systemd ועל SSH, ואז מגיע תרחיש: ״קיבלת התראה בשלוש בלילה. המחיצה של ‎/var בשרת Production מלאה ב־100%. הרצת df והוא מראה שהדיסק מלא, אבל du על כל התיקיות מסתכם בפחות מחצי. איפה המקום, ואיך אתה משחרר אותו בלי להפיל את השרת?״

מראיינים בתפקידי Linux ו־DevOps אוהבים את השאלה הזו, כי אי אפשר לענות עליה מרשימת פקודות שזוכרים בעל פה. היא בודקת אם אתם מבינים מה קורה במערכת הקבצים מתחת לפקודות, ואם אתם יודעים לעבוד על שרת חי בלי לגרום נזק.

למה df ו־du לא מסכימים?

בלינוקס, השם של קובץ בתיקייה הוא רק קישור ל־inode. הנתונים עצמם שייכים ל־inode. כשמריצים rm, מוחקים את הקישור ומורידים את ה־link count. מערכת הקבצים משחררת את הבלוקים רק כששני תנאים מתקיימים: אף שם כבר לא מצביע על ה־inode, ואף תהליך לא מחזיק אותו פתוח.

• ▸df שואל את מערכת הקבצים ישירות כמה בלוקים תפוסים וכמה פנויים. הוא רואה הכול, כולל נתונים של קבצים שכבר אין להם שם.
• ▸du עובר על עץ התיקיות קובץ אחרי קובץ וסוכם את הבלוקים. מה שאין לו נתיב בתיקייה, du פשוט לא יכול לספור.
• ▸לכן פער גדול בין השניים אומר כמעט תמיד שיש על הדיסק נתונים שאין דרך להגיע אליהם דרך נתיב רגיל.

החשוד המרכזי: לוג שנמחק אבל עדיין פתוח

התרחיש הקלאסי: אפליקציה כותבת ל־‎/var/log/app/app.log, הקובץ מגיע ל־40GB, ומישהו בצוות ״פותר״ את הבעיה עם rm. הקובץ נעלם מ־ls, אבל תהליך ה־Java או ה־nginx עדיין מחזיק אליו File Descriptor פתוח וממשיך לכתוב. המקום לא חוזר, ו־df ממשיך להראות 100%. מי שמחק בטוח שפינה 40GB, ובפועל לא שוחרר אפילו בייט אחד.

# כמה תפוס לפי מערכת הקבצים
df -hT /var

# כמה תפוס לפי הקבצים הגלויים, בלי לחצות למחיצות אחרות
du -xh --max-depth=1 /var | sort -h

# קבצים פתוחים שה־link count שלהם 0, כלומר נמחקו
lsof -nP +L1

# בלי lsof: חיפוש ישיר ב־/proc
find /proc/[0-9]*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null

COMMAND  PID USER FD   TYPE DEVICE    SIZE/OFF NLINK NODE NAME
java    2481 app   7w  REG  253,2 42949672960     0 1311 /var/log/app/app.log (deleted)

איך משחררים את המקום בלי להפיל את השרת

• ▸הדרך הנקייה: לגרום לתהליך לסגור את הקובץ. בהרבה שירותים reload מספיק כדי שיפתחו מחדש את קבצי הלוג, למשל systemctl reload nginx. אם השירות לא תומך בזה, restart בחלון זמן מתוכנן.
• ▸כשאי אפשר לאתחל עכשיו: לקצץ את הקובץ דרך ה־File Descriptor של התהליך. המקום משתחרר מיד, והתהליך ממשיך לכתוב כרגיל.
• ▸מה לא לעשות: לא להרוג תהליכים באקראי עם kill -9, ולא להמשיך למחוק קבצים אחרים ״כדי לפנות מקום״. זה לא יעזור, כי המקום תפוס על ידי הקובץ שכבר נמחק.

# לפי ה־PID וה־FD מהפלט של lsof
: > /proc/2481/fd/7

# בדיקה שהמקום חזר
df -h /var

lsof לא מצא כלום? עוד שתי סיבות

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

• ▸קבצים מוסתרים מתחת ל־mount point: נניח ש־‎/var/log היא מחיצה נפרדת. אם בזמן שהיא לא הייתה מחוברת, למשל אחרי Boot שבו ה־mount נכשל, שירות כתב לוגים לתיקייה, הקבצים נכתבו בפועל למחיצה של ‎/var. אחרי שהמחיצה חוברה היא מסתירה אותם, ו־du לא רואה אותם. bind mount של ‎/var למקום אחר מראה את התיקייה בלי מה שמחובר מעליה.
• ▸בלוקים שמורים ב־ext4: כברירת מחדל ext4 שומר כ־5% מהבלוקים ל־root, כדי שהמערכת תמשיך לתפקד גם כשמשתמשים רגילים מילאו את הדיסק. זו הסיבה ש־Used ועוד Avail ב־df לא מסתכמים ל־Size. בדיסק של 2TB מדובר בכ־100GB. במחיצות נתונים אפשר להקטין את האחוז עם tune2fs -m, במחיצת השורש עדיף להשאיר אותו.

# מה מסתתר בתיקייה מתחת למחיצה שמחוברת עליה
mkdir -p /mnt/var-under
mount --bind /var /mnt/var-under
du -sh /mnt/var-under/log
umount /mnt/var-under

# כמה בלוקים שמורים ל־root במחיצת ext4
tune2fs -l "$(findmnt -no SOURCE /var)" | grep -i 'reserved block count'

השאלה שכמעט תמיד מגיעה אחרי: אין מקום, אבל יש מקום

התרחיש ההפוך: df -h מראה 60% פנוי, אבל האפליקציה נופלת עם No space left on device. הפעם הבעיה היא לא בלוקים אלא inodes. לכל קובץ יש inode אחד, ובמערכות כמו ext4 מספר ה־inodes נקבע כשיוצרים את מערכת הקבצים. מיליוני קבצים קטנים, כמו קבצי session של PHP או תור מיילים שנתקע, יכולים לגמור את ה־inodes הרבה לפני שנגמר המקום.

df -i /var

# איפה יש הכי הרבה קבצים (GNU du)
du -x --inodes --max-depth=2 /var | sort -n | tail

איך מונעים את זה מראש

• ▸logrotate מוגדר נכון: אחרי סיבוב הלוג שולחים לשירות reload בבלוק postrotate, או משתמשים ב־copytruncate לאפליקציות שלא יודעות לפתוח מחדש את הלוג. ל־copytruncate יש מחיר: שורות שנכתבות בין ההעתקה לקיצוץ עלולות ללכת לאיבוד.
• ▸הגבלת נפח ל־journald: הגדרת SystemMaxUse בקובץ ‎/etc/systemd/journald.conf, או ניקוי חד פעמי עם journalctl --vacuum-size=500M.
• ▸ניטור והתראה גם על אחוז דיסק, גם על אחוז inodes וגם על קצב הגדילה. 85% שהצטברו במשך חודש הם לא אותו סיפור כמו 85% שהגיעו בשעה.
• ▸מחיצות נפרדות ל־‎/var/log ולתיקיות של מסדי נתונים, כדי שלוג שיצא משליטה לא ימלא את מחיצת השורש ויפיל את כל השרת.

שאלות המשך שכדאי להיות מוכנים אליהן

• ▸מה ההבדל בין hard link ל־soft link? hard link הוא עוד שם לאותו inode, ולכן הנתונים נמחקים רק כשכל השמות נמחקו. soft link הוא קובץ נפרד שמכיל נתיב, והוא נשבר אם המקור נמחק.
• ▸מה ההבדל בין truncate -s 0 ל־rm? truncate מאפס את התוכן ומשאיר את הקובץ ואת ה־inode, ולכן תהליך שכותב אליו ממשיך כרגיל והמקום חוזר. rm מוחק רק את השם.
• ▸למה ls -l ו־du מראים גדלים שונים לאותו קובץ? ls מציג את הגודל הלוגי, ו־du את הבלוקים שהוקצו בפועל. בקובץ Sparse, כמו דיסק של מכונה וירטואלית, ls יכול להראות 100GB ו־du רק 3GB.
• ▸איך מגדילים מחיצת LVM בלי השבתה? lvextend עם הדגל ‎-r מגדיל את ה־Logical Volume ואת מערכת הקבצים יחד. ext4 ו־XFS תומכים בהגדלה בזמן שהמחיצה מחוברת. הקטנה היא כבר סיפור אחר, ו־XFS לא תומכת בה בכלל.
• ▸מה ההבדל בין reload ל־restart ב־systemd? reload מבקש מהשירות לטעון מחדש את ההגדרות בלי לעצור, אם השירות תומך בזה. restart עוצר ומפעיל מחדש, כולל ניתוק החיבורים הפעילים.

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