
پر شدن دیسک لینوکس همیشه به معنی تمام شدن گیگابایتهای سرور نیست. ممکن است فضای ذخیرهسازی آزاد داشته باشید، اما ایجاد فایل تازه با پیام No space left on device شکست بخورد؛ در این وضعیت، inode، سهمیه یا فایلسیستم مقصد هم باید بررسی شوند. راه درست از پیدا کردن محدودیت واقعی شروع میشود، نه پاک کردن تصادفی پوشهها.
این راهنما برای مدیر VPS یا سرور اختصاصی است که با توقف آپلود، خطای نوشتن لاگ، اختلال بکاپ یا مشکل برنامه روبهرو شده است. فرمانهای تشخیصی زیر دادهای حذف نمیکنند، ولی پیمایش پوشههای بزرگ میتواند بار دیسک ایجاد کند. آنها را روی مسیر مرتبط و با سطح دسترسی متناسب اجرا کنید.
اول مشخص کنید کدام مسیر امکان نوشتن ندارد
متن کامل خطا، ساعت رخداد و مسیر مقصد را ثبت کنید. خطا هنگام آپلود در پوشه سایت رخ میدهد، هنگام ساخت فایل موقت در /tmp یا هنگام نوشتن داده در /var؟ این مسیرها ممکن است روی فایلسیستمهای جدا باشند. فضای خالی /home نمیتواند مشکل پر بودن /var را بهطور خودکار حل کند.
اگر سایت فروشگاهی است، وضعیت ثبت سفارشها و نوشتن دیتابیس را بررسی کنید و تغییرات غیرضروری را متوقف کنید. ساخت یک بکاپ حجیم تازه روی همان فضای پر، فشار بیشتری ایجاد میکند. پیش از پاکسازی، روشن کنید نسخه مستقل قابل بازیابی دارید و کدام اطلاعات باید حفظ شوند. برای آشنایی با مشاهده وضعیت سرویسها، چکلیست مدیریت سرور لینوکس با خط فرمان نقطه شروع مناسبی است.
تفاوت فضای دیسک و inode چیست؟
فضای دیسک ظرفیت نگهداری داده است. inode در فایلسیستمهای متداول لینوکس، اطلاعات مدیریتی مربوط به اشیایی مانند فایل و پوشه را نگه میدارد. تعداد زیادی فایل کوچک میتواند منابع inode را مصرف کند، حتی اگر مجموع حجم محتوا کم باشد. رفتار و نحوه تخصیص inode به نوع فایلسیستم وابسته است؛ آن را صرفاً یک ظرفیت ثابت و یکسان در تمام سیستمها فرض نکنید.
یک مثال فرضی را در نظر بگیرید: پوشه کش برنامه میلیونها فایل چندصدبایتی ساخته است. نمودار فضای حجمی هنوز ظرفیت آزاد نشان میدهد، اما برنامه برای فایل بعدی با محدودیت مواجه میشود. در سناریوی دیگر، چند آرشیو بکاپ بسیار بزرگ ظرفیت حجمی را پر کردهاند، در حالی که تعداد فایلها زیاد نیست. اقدام اصلاحی این دو مسئله یکسان نیست.

جدول تشخیص اولیه پر شدن دیسک لینوکس
| مشاهده | بررسی بعدی | جهت اقدام |
|---|---|---|
| فضای حجمی نزدیک ظرفیت است | پوشههای پرحجم در همان فایلسیستم | شناسایی مالک داده و سیاست نگهداری |
| فضا آزاد است، inode پر است | تعداد فایلها در کش، صف یا سشن | اصلاح تولید و انقضای فایلهای کوچک |
| فقط یک حساب خطا میدهد | سهمیه همان حساب و مجوز مسیر | بررسی محدودیت کاربر یا سرویس |
| فایل حذف شده ولی فضا برنگشته | فایل باز در پردازش فعال و ویژگی فایلسیستم | بررسی سرویس و آزادسازی کنترلشده |
| خطا فقط در یک mount دیده میشود | ظرفیت و وضعیت همان محل اتصال | تمرکز بر فایلسیستم مقصد |
۱. ظرفیت و inode مسیر خطادار را بررسی کنید
برای یک نمونه که خطا در /var رخ داده، از این فرمانها استفاده کنید. مسیر را با محل واقعی مشکل جایگزین کنید:
df -h /var
df -i /varدر خروجی اول، ستونهای Available و Use% را کنار نام فایلسیستم و محل اتصال ببینید. خروجی دوم وضعیت inode را نشان میدهد. تفسیر درصدها باید با نوع فایلسیستم، فضای رزروشده و نیاز سرویس همراه باشد. رسیدن به محدودیت inode میتواند ساخت فایل را با وجود فضای حجمی آزاد متوقف کند؛ این نکته در راهنمای رسمی cPanel برای بررسی مصرف دیسک نیز توضیح داده شده است.
اگر خطای برنامه مربوط به /tmp است، همین دو بررسی را برای /tmp تکرار کنید. این مسیر گاهی از tmpfs استفاده میکند و محدودیت آن با دیسک اصلی یکسان نیست. همچنین در کانتینر یا محیط میزبانی محدودشده، ظرفیت قابل استفاده ممکن است تابع سهمیه یا لایه ذخیرهسازی همان محیط باشد. خروجی میزبان را بدون شناخت معماری به داخل کانتینر تعمیم ندهید.
۲. پوشه پرمصرف را با دامنه محدود پیدا کنید
پس از شناخت فایلسیستم، پوشههای سطح اول همان مسیر را بررسی کنید. نمونه زیر برای نسخه GNU ابزار du نوشته شده است:
sudo du -x -h --max-depth=1 /varگزینه -x مانع عبور پیمایش به فایلسیستمهای دیگر میشود و عمق یک، گزارش را به سطح نخست محدود میکند. سپس فقط وارد شاخهای شوید که مصرف غیرعادی دارد و بررسی را کوچکتر کنید. اگر پیام Permission denied دریافت کردید، بخشی از محتوا در محاسبه دیده نشده است؛ خطاها را پنهان نکنید و خروجی ناقص را گزارش کامل ندانید.
برای نمونه، اگر /var/log رشد کرده، ابتدا تولیدکننده لاگ و سرعت رشد را شناسایی کنید. اگر /var/lib بزرگ است، احتمال وجود داده سرویس یا دیتابیس مطرح میشود؛ این مسیر محل پاکسازی عمومی نیست. آرشیو قدیمی، فایل عملیاتی و داده دیتابیس ممکن است اندازه مشابه داشته باشند اما پیامد حذفشان کاملاً متفاوت است.
۳. اگر inode پر است، به دنبال فایلهای کوچک باشید
در نسخه GNU ابزار du، بررسی تعداد inode در شاخه مشخص امکانپذیر است:
sudo du -x --inodes --max-depth=1 /varاز مسیر مشکلدار شروع کنید و شاخه پرمصرف را مرحلهبهمرحله محدود کنید. کش، فایل سشن، صف پیام و خروجی موقت از گزینههای بررسی هستند، اما هیچکدام بدون شناخت برنامه قابل حذف فرض نمیشوند. اگر فرمان روی توزیع شما پشتیبانی نشد، راهنمای نسخه نصبشده را ببینید؛ گزینههای GNU با همه پیادهسازیها یکسان نیستند.
فرض کنید سشنها بدون انقضا انباشته شدهاند. حذف دستی امروز شاید سرویس را باز کند، اما تا زمانی که پاکسازی دورهای یا تنظیم انقضا اصلاح نشده، مشکل برمیگردد. همچنین پاک شدن سشن فعال میتواند کاربر را از حساب خارج کند. راهکار بهتر، استفاده از روش نگهداری خود برنامه و آزمون نتیجه در بازه کنترلشده است.
۴. چرا df و du عدد یکسان نشان نمیدهند؟
df وضعیت تخصیص در سطح فایلسیستم را نشان میدهد، در حالی که du مسیرهای قابل پیمایش را بررسی میکند. تفاوت دامنه بررسی، مجوز دسترسی، فضای رزروشده، فایلهای sparse، snapshotها و فایلهای حذفشدهای که هنوز باز هستند، میتوانند در تفاوت خروجی نقش داشته باشند. انتظار برابری دقیق این دو عدد بدون توجه به شرایط درست نیست.
برای فایل حذفشدهای که سرویس هنوز آن را باز نگه داشته، مدیر سیستم میتواند با ابزاری مانند lsof مالک پردازش را بررسی کند. تا وقتی ارجاعهای لازم بسته نشوند، ممکن است فضای فایل آزاد نشود. راهاندازی مجدد کورکورانه کل سرور اقدام اول نیست؛ ابتدا سرویس و روش درست باز کردن مجدد لاگ را مشخص کنید و اثر توقف آن را بسنجید.
۵. لاگها را با سیاست نگهداری مدیریت کنید
در سرورهای مبتنی بر systemd، فرمان زیر مصرف فایلهای journal را گزارش میکند:
journalctl --disk-usageاین عدد تمام مصرف /var/log نیست؛ گزارشهای برنامهها ممکن است جدا باشند. مستندات رسمی journalctl تفاوت نمایش مصرف و عملیات vacuum را توضیح میدهد. حذف آرشیوهای journal نیز جای تعیین سیاست نگهداری را نمیگیرد. پیش از کم کردن سابقه، نیاز عیبیابی و مدت نگهداری موردنیاز مجموعه را مشخص کنید.
برای لاگ متنی برنامه، تنظیم چرخش و بازگشایی فایل باید با همان سرویس سازگار باشد. فشردهسازی روی دیسک کاملاً پر هم ممکن است به فضای موقت نیاز داشته باشد. اگر لاگ با سرعت غیرعادی رشد میکند، علت تکرار خطا را بررسی کنید؛ کاهش حجم بدون رفع تولیدکننده، فقط زمان میخرد.
چه زمانی افزایش فضای سرور منطقی است؟
اگر مصرف عادی و موردنیاز پروژه واقعاً رشد کرده، ظرفیت بیشتر قابل بررسی است. اما افزایش دیسک لزوماً محدودیت سهمیه، inode یا mount اشتباه را حل نمیکند. در توسعه ذخیرهسازی باید لایههای دیسک، پارتیشن، LVM و فایلسیستم متناسب با معماری بررسی شوند. هرکدام مرحله جدا دارد و نسخه پشتیبان و برنامه بازگشت میخواهد.
برای پیشگیری، مصرف حجمی و inode را همزمان پایش کنید و سرعت رشد را ثبت کنید. ظرفیت آزاد امروز را با رشد روزانه و زمان لازم برای رسیدگی مقایسه کنید؛ یک درصد هشدار ثابت برای تمام سرورها مناسب نیست. اگر مشکل به پایداری سایت منجر شده، راهنمای رفع خطای 503 وردپرس برای بررسی لایه برنامه هم مفید است.
پرسشهای رایج
چرا با وجود فضای خالی، آپلود شکست میخورد؟
inode، سهمیه حساب، ظرفیت محل فایل موقت و مجوز مسیر را بررسی کنید. متن خطا و مسیر دقیق تعیین میکند کدام عامل محتملتر است؛ فضای کل سرور بهتنهایی کافی نیست.
آیا پاک کردن پوشه tmp راهکار مناسبی است؟
حذف عمومی آن میتواند به فایلهای فعال برنامه آسیب بزند. ابتدا مالک و نیاز فایلها را مشخص کنید و از سیاست نگهداری سازگار با سرویس استفاده کنید. راهنمای پوشه tmp و گزینههای mount جزئیات مرتبط را توضیح میدهد.
آیا برای بررسی این مشکل به root نیاز داریم؟
بررسی اولیه df معمولاً بدون root ممکن است، ولی مشاهده کامل بعضی پوشهها به مجوز بیشتر نیاز دارد. در هاست اشتراکی از ابزار پنل و پشتیبانی کمک بگیرید و محدودیت دسترسی را در نتیجه بررسی ذکر کنید.
گزارش درست برای رفع پایدار مشکل
مسیر خطادار، خروجی df، شاخه پرمصرف، سرعت رشد و تغییر انجامشده را ثبت کنید. پس از اصلاح، همان عملیات ناموفق را تکرار و وضعیت سرویس و داده را کنترل کنید. برای کمک در تشخیص و برنامه نگهداری، محدوده مدیریت سرور و سایت آفاق هاست را بررسی کنید؛ رفع پایدار پر شدن دیسک لینوکس به شناخت داده و علت رشد آن وابسته است.
سرویسهای مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.



پرسشها و دیدگاههای شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.