WIUNIX ACADEMY
عیب‌یابی کمبود فضای دیسک و inode در لینوکس
پیش از حذف فایل، مشخص کنید مشکل از ظرفیت، تعداد inode یا فایل حذف‌شده‌ای است که هنوز باز مانده؛ سپس مسئول داده یا سرویس مربوط را پیدا کنید.
محیطت را انتخاب کنآموزش متناسب با محیط تو
کجا اجرا می‌کنی؟
سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.
آموزش متناسب با مقادیر تو
تنظیمات این آموزش
مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.
آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.
تنظیم مقادیر برای محیط من4 مقدار قابل‌تغییر
از اینجا شروع کن
در پایان چه چیزی خواهی داشت؟
فایل‌سیستم مشکل‌دار را پیدا کنید، مصرف بلوک و inode را جدا بسنجید و فرایندی را که دادهٔ حذف‌شده را نگه داشته شناسایی کنید؛ بدون پاک‌سازی کورکورانه.
سیستم‌عامل‌ها و نسخه‌های پوشش‌داده‌شده
مسیرهای این آموزش با مستندات رسمی ابزار و توزیع انتخابی بررسی شده‌اند. فرمان‌های آموزشی روی سرویس شما اجرا نشده‌اند؛ نتیجهٔ محیط خودتان را در هر گام بررسی کنید.
قبل از شروع
- دسترسی مجاز برای بررسی فایل‌سیستم و فرایندهای میزبان؛ مسیر دقیق خطای برنامه را می‌دانید.
- ابزارهای اندازه‌گیری مصرف فضا و بررسی فایل‌های باز و lsof در محیط انتخابی موجودند؛ برای شاخهٔ بزرگ، زمان مناسب اسکن دارید.
- پیش از آزادسازی، مسئول داده، نیاز نگهداری شواهد و راه بازیابی مشخص می‌شود؛ این راهنما دستور حذف عمومی داده نیست.
پیش از حذف، معنی خطا را روشن کنید
پیام ENOSPC همیشه به معنی وجود چند فایل بزرگ نیست. ممکن است inode تمام شده باشد یا فایل‌سیستم، سهمیه یا لایهٔ نوشتنی کانتینر به محدودیت دیگری رسیده باشد. EDQUOT به سهمیه و EROFS به حالت فقط‌خواندنی مربوط است؛ حذف تصادفی لاگ، آن‌ها را درست نمی‌کند.
در این راهنما فقط یک فایل‌سیستم موجود را بررسی می‌کنیم. تنظیم mount، سهمیه یا بلوک رزروشده تغییر نمی‌کند و برای دادهٔ اپلیکیشن فهرست حذف عمومی ارائه نمی‌شود.
قدم بعدی
پیش از شروع، ابزار و تفاوت‌های توزیع را بررسی کنید
این گام روی همان میزبان آزمایش یا عیب‌یابی اجرا می‌شود. نام و نسخهٔ سیستم‌عامل و بسته‌های فهرست‌شده را با محیط انتخابی تطبیق دهید. اگر ابزاری نصب نیست، ابتدا از مخزن رسمی فعال و روند مجاز مدیریت بستهٔ خود آن را نصب کنید؛ این آموزش سرور موجود را دوباره نصب یا مخزنش را عوض نمی‌کند.
مسیر پیش‌فرض برای Ubuntu 26.10 بررسی شده است؛ گزینه‌های 26.04 LTS و 24.04 LTS نیز در دسترس‌اند. بسته‌ها را با همان انتشار و پیکربندی واقعی میزبان تطبیق دهید.
در RPM نام بستهٔ ps برابر procps-ng است، نه procps. تشخیص df، du و lsof روی فایل‌سیستم سوارشده انجام می‌شود، اما تفسیر نهایی باید نوع فایل‌سیستم را لحاظ کند: فضای رزروشدهٔ ext4 را به XFS تعمیم ندهید. روی XFS، quota و در فایل‌سیستم‌های اشتراکی، snapshot و extents مشترک می‌توانند محاسبه را تغییر دهند. هیچ فرمان repair یا تغییر reserve/quota در این روند وجود ندارد.
ترمینال میزبان مجاز معرفی‌شده در همین بخش
cat /etc/os-release
dpkg-query -W coreutils util-linux procps lsof
command -v df du findmnt ps lsof statبسته و ابزار لازم شناسایی شده است؛ خطا یا نبود ابزار را پیش از ادامه رفع کنید.
قدم بعدی
مسیر خطا روی کدام فایل‌سیستم است؟
بررسی را از /var شروع کنید و منبع mount، نوع فایل‌سیستم و گزینه‌های آن را ببینید. یک mount تو‌در‌تو می‌تواند مسیر را از فایل‌سیستم والد جدا کند؛ کانتینر هم ممکن است دید متفاوتی از میزبان داشته باشد.
تا مطمئن نشده‌اید همان محل خطای برنامه را اندازه می‌گیرید، درصد مصرف را مبنای تصمیم نگذارید. فضای آزاد و inode آزاد باید هر دو برای همان مسیر ثبت شوند.
ترمینال همان میزبان معرفی‌شده در توضیح گام
test -d '/var' || exit 1
findmnt --target '/var' -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT -- '/var'
df -i -- '/var'mount واقعی مسیر و وضعیت بلوک‌ها و inodeهای همان فایل‌سیستم مشخص‌اند.
از روی اندازه‌گیری، مسیر بررسی را انتخاب کنید
اگر بایت آزاد دارید ولی inode رو به اتمام است، دنبال تعداد زیاد فایل کوچک بگردید. اگر مصرف ثبت‌شدهٔ فایل‌سیستم از جمع شاخه‌ها خیلی بیشتر است، فایل حذف‌شدهٔ باز، snapshot یا دادهٔ پنهان زیر mount را بررسی کنید.
در Btrfs، ZFS، ذخیره‌سازی thin و فایل‌سیستم سهمیه‌دار، ابزار بومی همان لایه هم لازم است. اندازهٔ ظاهری فایل sparse با بلوک تخصیص‌یافته یکی نیست؛ این دو عدد را به جای هم مقایسه نکنید.
قدم بعدی
بررسی را به یک فایل‌سیستم محدود کنید
ابتدا مصرف شاخه‌های سطح اول /var را ببینید. گزینهٔ one-file-system مانع رفتن به فایل‌سیستم دستگاه دیگر می‌شود، اما اسکن را کم‌هزینه نمی‌کند. در شاخهٔ بزرگ ممکن است I/O قابل توجهی ایجاد شود.
پیام خطای دسترسی یا ناپدیدشدن فایل را پنهان نکنید؛ در آن حالت جمع نهایی کامل نیست. خروجی را برای انتخاب شاخهٔ بعدی به کار ببرید، نه برای صدور فوری دستور حذف.
ترمینال همان میزبان معرفی‌شده در توضیح گام
sudo du -x -h --max-depth=1 -- '/var'شاخهٔ پرمصرف همان فایل‌سیستم پیدا شده و محدودیت‌ها و خطاهای اسکن نیز دیده شده‌اند.
قدم بعدی
شاخه‌ای را پیدا کنید که فایل‌های بسیار زیادی دارد
اگر بررسی اولیه کمبود inode را نشان داد، تعداد inode را یک سطح پایین‌تر در /var/log مقایسه کنید. این روش لازم ندارد فهرست میلیون‌ها نام فایل را برای sort روی یک دیسک پر ذخیره کنید.
hardlink و تغییر هم‌زمان فایل‌ها روی شمارش اثر می‌گذارند. حتی اگر cache بیشترین سهم را داشت، حذف آن باید از روند نگهداری همان برنامه انجام شود؛ تعداد زیاد به‌تنهایی مجوز پاک‌سازی نیست.
ترمینال همان میزبان معرفی‌شده در توضیح گام
sudo du -x --inodes --max-depth=1 -- '/var/log'شاخهٔ دارای inode زیاد، بدون حذف فایل و بدون عبور از فایل‌سیستم هدف شناسایی شده است.