فضای دیسک داریم، اما No space left on device می‌گیریم

موقعیت بحرانی: برنامه دیگر فایل تازه نمی‌سازد. کسی یک لاگ بزرگ را پاک کرده، اما فضای آزاد زیاد نشده است. یا گزارش ظرفیت هنوز جا نشان می‌دهد و خطای No space left on device همچنان ادامه دارد. پیش از حذف فایل‌های بیشتر، معلوم کنیم کدام منبع واقعاً تمام شده است.

اول همان مسیر خطادار را بررسی کنیم

در مثال زیر مسیر /var فقط نمونه است؛ آن را با پوشه‌ای که برنامه واقعاً در آن خطا می‌گیرد جایگزین کنید. این فرمان‌ها برای تشخیص روی Linux هستند:

findmnt -T /var
df -h /var
df -i /var
sudo lsof +L1

df -h مصرف بلوک داده را نشان می‌دهد؛ df -i وضعیت inode را. تمام‌شدن inode در فایل‌سیستم‌هایی که چنین محدودیتی دارند می‌تواند جلوی ساخت فایل را بگیرد، حتی وقتی ظرفیت داده باقی است. مسیر برنامه ممکن است روی Mount دیگری باشد؛ گزارش فضای ریشه به‌تنهایی جواب نیست.

اگر inode تمام شده است

تولیدکننده انبوه فایل‌های کوچک را محدود کنید؛ مثلاً Job معیوبی که برای هر تلاش ناموفق، فایل موقت تازه می‌سازد. پاکسازی باید در پوشه مشخص و با شناخت مالک و سیاست نگهداری انجام شود. Cache قابل‌بازسازی با داده اصلی، صف کار و فایل تراکنشی یکسان نیست.

جابه‌جایی فایل‌ها داخل همان فایل‌سیستم معمولاً inode آزاد نمی‌کند. هدف، کاهش تعداد فایل‌های واقعاً غیرضروری روی همان فایل‌سیستم است، نه مرتب‌تر کردن نام پوشه‌ها. در حادثه‌ای که علت ایجاد فایل هنوز فعال است، پاکسازی فقط چند دقیقه زمان می‌خرد.

اگر فایل حذف شده اما هنوز باز است

خروجی lsof +L1 می‌تواند فایل‌های باز با شمار پیوند کمتر از یک را نشان دهد. یک نتیجه بزرگ و مرتبط را به PID و سرویس مالک وصل کنید. مسیر حذف‌شده ممکن است هنوز توسط پردازش نگه داشته شده باشد؛ حذف نام فایل لزوماً به معنی آزادشدن فوری تمام بلوک‌ها نیست.

اگر فایل، لاگ همان سرویس است، روش مستند بازکردن مجدد لاگ را بررسی کنید. اگر چنین امکانی وجود ندارد، راه‌اندازی مجدد کنترل‌شده همان سرویس با شناخت اثر آن می‌تواند Handle را آزاد کند. صرف داشتن کلمه «deleted» مجوز کشتن پردازش نیست. فایل‌های پایگاه داده را با دستکاری مسیر /proc یا خالی‌کردن فایل‌دسکریپتور اصلاح نکنید.

از کجا بفهمیم کار تمام شده؟

دوباره هر دو گزارش ظرفیت و inode را روی همان مسیر بگیرید. یک عملیات کوچک و مجازِ ساخت و نوشتن را از مسیر خود برنامه امتحان کنید و سرعت رشد مجدد را ببینید. اگر شواهد با این دو حالت تطبیق ندارد، Quota، فایل‌سیستم فقط‌خواندنی و خطای ذخیره‌سازی را جدا بررسی کنید؛ ENOSPC را صرفاً به لاگ نسبت ندهید.

تصمیم نجات‌دهنده: پیش از حذف بعدی، مشخص کنیم کمبودِ بلوک داریم، inode تمام شده یا یک پردازش هنوز فضای حذف‌شده را نگه داشته است.

منابع: گزارش بلوک و inode در GNU df، فیلتر فایل‌های بدون پیوند در lsof.