خطای No space left on device با وجود فضای خالی؛ inode را پیدا کنید

گاهی پیام No space left on device را می‌بینید، اما df -h هنوز چند گیگابایت فضای خالی نشان می‌دهد. دلیل می‌تواند تمام‌شدن «inode» باشد. هر فایل یا پوشه در فایل‌سیستم برای نگهداری مشخصاتش یک inode مصرف می‌کند. پس هزاران فایل کوچک هم می‌توانند سهمیهٔ تعداد فایل را تمام کنند، حتی اگر حجم آن‌ها کم باشد. در این وضعیت پاک‌کردن یک فایل ویدیویی بزرگ معمولاً کمکی نمی‌کند؛ باید پوشه‌ای را پیدا کنید که تعداد زیادی فایل ریز دارد.

با SSH این دو فرمان را اجرا کنید:

در خروجی اول، Use% فضای ذخیره‌سازی را نشان می‌دهد. در خروجی دوم، IUse% تعداد inodeهای مصرف‌شده را نشان می‌دهد. اگر فضای اول مثلاً 60 درصد است ولی IUse% برابر 100، سیستم جایی برای ساخت فایل جدید ندارد. ممکن است وردپرس نتواند تصویر یا نشست تازه بسازد، ایمیل تحویل نشود یا برنامه هنگام نوشتن لاگ خطا دهد.

به ستون Mounted on نگاه کنید تا بفهمید کدام پارتیشن پر شده است. اگر /home یا پوشهٔ سایت پارتیشن جدا دارد، باید همان مسیر را بررسی کنید. راهنمای df گزینهٔ نمایش inodeها را شرح می‌دهد؛ از دستورهای خواندنی شروع کنید و فعلاً چیزی پاک نکنید.

اگر دسترسی مدیر دارید، ابتدا پوشه‌های سطح اول را از نظر تعداد فایل بررسی کنید. برای یک مسیر مشخص، مثل پوشهٔ کش سایت، این فرمان تعداد فایل‌های معمولی را می‌شمارد:

به‌جای USER نام کاربر حساب را بگذارید. این فرمان فقط تعداد را می‌شمارد؛ نام یا محتوای فایل‌ها را تغییر نمی‌دهد. مسیر را پیش از اجرا دوباره بخوانید تا از پوشهٔ درست مطمئن شوید. در هاست بدون SSH، بخش File Usage یا Disk Usage پنل ممکن است شمار فایل‌های حساب را نشان دهد؛ نام منو به شرکت میزبان بستگی دارد.

جست‌وجوی کامل در کل / روی سرور بزرگ می‌تواند زمان و پردازنده مصرف کند. از یک مسیر محدود شروع کنید، مثلاً wp-content/cache، پوشهٔ نشست برنامه یا فایل‌های موقت پروژه. اگر عدد خیلی بزرگ است، آن را با پوشه‌های خواهر مقایسه کنید. برای پیدا کردن فایل‌های تازه، می‌توانید فهرست نام و زمان تغییر را بگیرید؛ خودکار پاک‌کردن بر اساس سن بدون دانستن کاربرد فایل امن نیست.

کش بازسازی‌شدنی معمولاً گزینهٔ اول است، اما آن را از دکمهٔ پاک‌سازی افزونه یا پنل خود برنامه پاک کنید. این ابزار می‌داند کدام فایل‌ها متعلق به کش‌اند. اگر تعداد زیادی فایل نشست قدیمی دارید، ابتدا از پشتیبانی بپرسید کدام مسیر و مدت نگهداری درست است؛ حذف نشست فعال ممکن است کاربران را از حساب خارج کند یا سبد خرید را خالی کند.

پوشهٔ ایمیل را دستی پاک نکنید؛ هر فایل می‌تواند بخشی از یک پیام باشد و حذف مستقیم ممکن است صندوق را خراب کند. فایل‌های آپلودشدهٔ مشتری، عکس محصول، بکاپ و پوشهٔ دادهٔ پایگاه داده هم «فایل اضافه» نیستند. همین‌طور /tmp ممکن است فایل‌هایی داشته باشد که برنامه در همین لحظه استفاده می‌کند. هیچ‌کدام را فقط از روی اسم پاک نکنید.

اگر با پشتیبانی میزبان تماس می‌گیرید، تصویر خروجی df -i، نام پارتیشن، زمان خطا و شمار فایل مسیر مشکوک را بفرستید. میزبان می‌تواند سهمیهٔ حساب و پوشه‌های خارج از دسترسی شما را ببیند و پاک‌سازی مناسب همان سیستم را اجرا کند.

بعد از پاک‌سازی کش یا فایل‌های موقتِ تأییدشده، df -i را دوباره اجرا کنید. اگر IUse% پایین آمده، یک فایل کوچک آزمایشی را از برنامه بسازید و سپس پاک کنید. سایت را باز کنید، ارسال فرم را تست کنید و به گزارش خطا نگاه کنید. اگر عدد همچنان 100 درصد است، احتمالاً پارتیشن یا سهمیهٔ دیگری پر شده یا فایل‌ها دوباره با سرعت زیاد ساخته می‌شوند.

برای یافتن علت تکرار، زمان دو بار بالا رفتن شمار فایل‌ها را ثبت کنید و با همان بازه، لاگ برنامه را مقایسه کنید. افزونه‌ای که برای هر بازدید فایل موقت تازه می‌سازد، ممکن است نیاز به اصلاح تنظیم یا به‌روزرسانی داشته باشد. اگر هم فضای واقعی دیسک پر است، راهنمای آزادکردن امن فضای دیسک لینوکس با دستورهای df و du مسیر جداگانه‌ای را دنبال می‌کند. هر بار فقط یک مسیر را تغییر دهید تا علت و نتیجه روشن بماند.

در cPanel شمار inode با حجم بایت یکی نیست. ممکن است Disk Usage چند گیگابایت فضای آزاد نشان دهد، اما سقف تعداد فایل حساب پر شده باشد. از میزبان بخواهید هم مصرف inode و هم سهمیهٔ حساب را اعلام کند. اگر فقط یک پوشهٔ سایت پر است، نام همان پوشه و تعداد تقریبی فایل‌ها را بفرستید؛ لازم نیست کل حساب را فشرده یا همهٔ فایل‌ها را دانلود کنید.

در VPS، مدیر می‌تواند پوشه‌ها را مرحله‌به‌مرحله پایین‌تر بشمارد. find روی یک مسیر مشخص فقط می‌خواند، اما اگر میلیون‌ها فایل باشد زمان‌بر است؛ آن را در ساعت کم‌ترافیک و روی مسیر محدود اجرا کنید. اگر نام پوشهٔ کش را نمی‌شناسید، اول تنظیم افزونه را بخوانید. حذف خودکار بر اساس پسوند tmp یا تاریخ راه مطمئنی نیست، چون برنامه ممکن است همان فایل را در حال استفاده داشته باشد.