نفاد المساحة هو أشيع سبب يجعل خادمًا يتوقف عن العمل دون أي نية سيئة في الأمر. فالموقع يعيد 500، وقاعدة البيانات لا تكتب، والبريد لا يخرج — بينما يبلّغ df -h في الوقت نفسه عن عدة غيغابايتات حرة. لنستعرض الحالات الثلاث التي يحدث فيها ذلك، وما يستحق معرفته عن SMART.

الحالة الأولى: نفدت الـ inodes

يحتفظ نظام الملفات بموردين محدودين: مساحة للمحتوى وسجلات عن الملفات. والثاني ينفد بمعزل عن الأول:

df -h
df -i

إذا كانت IUse% في الأمر الثاني 100، فالمشكلة في الـ inodes. المساحة موجودة، لكن لا يمكن إنشاء ملف واحد، ولا حتى فارغًا.

والجناة هم أنفسهم دائمًا: ملايين الملفات الصغيرة. جلسات PHP في /var/lib/php/sessions تعطّل جمع مهملاتها. ذاكرة تخزين مؤقت لتطبيق لا تُنظَّف أبدًا. طابور بريد عالق. دليل صور مصغّرة. ويمكن إيجادها هكذا:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

يسرد الأمر الأدلة الأكثر احتواءً على الملفات. وعلى نظام كبير يعمل دقائق — وهذا طبيعي.

الحالة الثانية: حُذف الملف ولم تعد المساحة

وضع أشد مكرًا. أزال أحدهم بـ rm سجلًا متضخمًا، لكن العملية التي تكتب فيه ما زالت تُبقيه مفتوحًا. لم يعد الملف في الدليل، والمساحة لا تزال مشغولة، وستبقى كذلك حتى تُعاد العملية إلى التشغيل.

sudo lsof +L1

يعرض الأمر الملفات التي لا روابط لها في نظام الملفات لكن ما زالت عملية تحتجزها. والعلاج هو إعادة تشغيل تلك العملية أو إعادة تحميلها برفق، لا مطاردة سؤال «أين ذهبت الغيغابايتات».

ومن هنا القاعدة: السجل المتضخم لا يُحذف بل يُقصّ، فيبقى الواصف المفتوح صالحًا للاستخدام:

sudo truncate -s 0 /var/log/huge.log

وفور ذلك اضبط التدوير — وإلا تكرر الأمر كله خلال أسبوع.

الحالة الثالثة: السجلات التهمتها

أين ذهبت المساحة بالضبط يظهر بالنزول مستوى بعد مستوى:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

تمنع الراية -x التجوال في أنظمة ملفات أخرى؛ وبدونها يزحف الإحصاء إلى /proc وإلى نقاط الوصل الشبكية. وكل ذلك أكثر راحة في ncdu إن كان متاحًا.

الملتهمون المعتادون:

  • journald. أمر واحد يحسم الأمر: journalctl --disk-usage. ويُحدّ بالسطر SystemMaxUse=500M في /etc/systemd/journald.conf ويُنظَّف مرة واحدة بـ journalctl --vacuum-size=200M؛
  • سجلات أدوات الأمان. تكتب Suricata بالإعداد الافتراضي ثلاثين نوعًا من الأحداث ولا تضبط لنفسها أي تدوير — وعلى خادم حقيقي أنتج ذلك 15 غيغابايت في يومين. والشيء نفسه يحدث مع audit.log ومع سجلات التنقيح في nginx؛
  • النسخ الاحتياطية المكتوبة على القرص نفسه ولا تُحذف أبدًا؛
  • ذاكرة apt المؤقتة — يعيد apt clean بضعة غيغابايتات من حين لآخر.

كلمة عن /boot

قسم صغير يمتلئ بالنوى القديمة. وهو لا يُسقط الموقع بنفسه، لكنه يوقف التحديثات تمامًا: فالنواة الجديدة لن تُثبَّت، ويعلق خلفها طابور الحزم كله. ويُعالَج بـ apt autoremove --purge، ويُمنع بتفعيل الحذف التلقائي للنوى غير المستخدمة في إعدادات التحديثات التلقائية.

SMART: أي السمات مهم

تحفّظ أولًا: على خادم افتراضي لا يكون SMART متاحًا عادة — فالقرص افتراضي ولا ترى الفيزيائي تحته. وهذا ليس عطلًا، بل ببساطة لا توجد بيانات. وكل ما يلي يخص الخوادم المخصصة والعتاد الخاص بك.

sudo smartctl -a /dev/sda

والسطر SMART overall-health self-assessment test result: PASSED ليس سببًا للاسترخاء: فهو يبقى أخضر عمليًا حتى يموت القرص. وما ينبغي النظر إليه هو العدادات المحددة:

  • 5، Reallocated_Sector_Ct — القطاعات المُعاد تخصيصها. وقيمة غير صفرية تعني أن القرص يتدهور بالفعل؛ وتزايدها مع الوقت يعني استبدله دون تأخير؛
  • 197، Current_Pending_Sector — قطاعات لا تُقرأ وتنتظر قرارًا. وهو الأكثر إثارة للقلق: إذ يعني عادة أن جزءًا من البيانات صار غير قابل للاسترداد؛
  • 198، Offline_Uncorrectable — الشيء نفسه، مؤكَّدًا بفحص؛
  • SSD: Percentage Used / Media_Wearout_Indicator — قدرة الكتابة المستهلكة. رقم متوقَّع، وهو الذي يُخطَّط الاستبدال بناءً عليه.

أما الحرارة وساعات التشغيل فلا تقولان شيئًا بذاتهما: فقرص بخمس سنوات تشغيل وعدادات أخطاء صفرية أكثر موثوقية من قرص جديد فيه 1 في السمة 197.

معنى المراقبة

كل ما سبق ردّ فعل على أمر وقع بالفعل. ومع ذلك فامتلاء القرص وتآكل الـ SSD عمليتان بطيئتان ومتوقَّعتان تمامًا: فمخطط الامتلاء على أسبوعين يُظهر تاريخ نفاد المساحة قبل وقوعه بكثير. والفرق بين «الموقع ساقط منذ الثالثة فجرًا» و«يجب تنظيف السجلات يوم الخميس» ليس سوى أن الرقم أمام عينيك. وشكل ذلك مجمّعًا تعرضه صفحة العرض التوضيحي أدناه.