رفع No space left on device؛ فضا، inode و سهمیه

در خروجی df -h ستون Use% درصد مصرف فضای هر بخش دیسک را نشان می‌دهد. اگر بخش مربوط به فایل خطادار ۱۰۰ درصد است، آن بخش جا ندارد؛ آزاد بودن بخش دیگری از دیسک به آن فضا اضافه نمی‌کند. مسیرهای فایل مثل نشانی اتاق‌اند و باید ببینیم روی کدام بخش قرار گرفته‌اند.

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

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

زمان رخداد و مسیر فایل یا سرویس را از لاگ بگیرید. ممکن است دیسک ریشه فضای آزاد داشته باشد ولی پارتیشن tmp یا محل لاگ پر باشد. فرمان‌های فقط‌خواندنی پایین وضعیت ظرفیت و inode را نشان می‌دهند:

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

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

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

در بعضی رخدادهای Apache، پیام دقیق به ساخت semaphore مربوط است. این حالت با پر بودن دیسک فرق دارد. وضعیت IPC و فرایندهای سرویس را بخوانید و مشخص کنید آیا اشیای مانده از فرایند متوقف‌شده وجود دارند یا حد واقعی سیستم رسیده است.

نمونهٔ قدیمی این مقاله همهٔ شناسه‌های منطبق با یک نام را به ipcrm می‌داد. چنین حذف گروهی می‌تواند منابع مورد استفاده را بردارد، بنابراین آن فرمان به‌عنوان راه‌حل عمومی باقی نمانده است. پاک کردن فقط یک شیء تأییدشده، یا تغییر محدودیت، نیاز به شناخت مالک، وضعیت سرویس و روش برگشت دارد. مقدار ثابت kernel.sem را بدون محاسبه روی هر سرور قرار ندهید.

پس از رفع علت، تنظیم سرویس را اعتبارسنجی کنید و فقط سرویس لازم را با روش نصب خود اعمال یا راه‌اندازی کنید. reboot کل سرور اولین قدم عمومی این خطا نیست. سپس پاسخ سایت، نوشته شدن لاگ و عملیات معمول برنامه را بررسی کنید.

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

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