رفع No Space Left on Device با وجود فضای خالی؛ مشکل inode در Linux

اگر در Linux با خطای No Space Left on Device روبه‌رو شده‌اید اما دستور df -h هنوز چند گیگابایت فضای خالی نشان می‌دهد، احتمال زیادی وجود دارد که مشکل از حجم دیسک نباشد و inodeهای فایل‌سیستم تمام شده باشند. این وضعیت مخصوصاً روی سرورهایی که میلیون‌ها فایل کوچک، Cache، Session، Mail Queue، Log، Docker Layer یا فایل موقت تولید می‌کنند دیده می‌شود.

inode چیست؟

در بسیاری از فایل‌سیستم‌های Linux، هر فایل و Directory یک inode دارد. inode اطلاعاتی مثل Owner، Permission، Timestamp و محل داده‌های فایل روی فایل‌سیستم را نگه می‌دارد.

GNU Coreutils نیز توضیح می‌دهد که گزینه df -i به‌جای Block Usage، اطلاعات مربوط به inodeها را نمایش می‌دهد. :chatgpt-content-reference{index=”1″}

بنابراین فایل‌سیستم می‌تواند از نظر حجم هنوز خالی باشد اما تعداد inodeهای قابل استفاده آن تمام شده باشد.

نشانه کلاسیک تمام‌شدن inode

مثلاً:

df -h

خروجی:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       100G   25G   75G  25% /

در ظاهر 75GB فضای آزاد دارید، اما:

df -i

ممکن است چیزی شبیه این ببینید:

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/vda1      6553600 6553600      0  100% /

در این حالت حتی ساخت یک فایل بسیار کوچک ممکن است Fail شود:

touch testfile
touch: cannot touch 'testfile': No space left on device

مرحله ۱: اول فضای واقعی دیسک را بررسی کنید

df -h

اگر Partition واقعاً 100% شده باشد، مشکل شما ممکن است همان کمبود Block باشد. اما اگر فضای قابل‌توجهی آزاد است، مرحله بعد inode است.

GNU df به‌صورت معمول میزان فضای Used و Available فایل‌سیستم‌های Mount‌شده را گزارش می‌کند. :chatgpt-content-reference{index=”2″}

مرحله ۲: inodeها را بررسی کنید

df -i

به ستون‌های زیر دقت کنید:

اگر IUse% نزدیک 100% باشد، باید تعداد فایل‌ها را کم کنید.

مرحله ۳: ببینید کدام Mount Point inode تمام کرده است

df -iT

گزینه -T نوع فایل‌سیستم را نیز نشان می‌دهد.

ممکن است فقط /var، /home یا Partition دیگری inode کم آورده باشد و Root Filesystem سالم باشد.

مرحله ۴: مسیرهای پرمصرف inode را پیدا کنید

یکی از بهترین ابزارها du –inodes است. GNU Coreutils این گزینه را مخصوص پیدا کردن Directoryهایی معرفی می‌کند که تعداد زیادی فایل دارند و inode مصرف می‌کنند. :chatgpt-content-reference{index=”3″}

برای بررسی Root:

sudo du --inodes -x -d 1 / 2>/dev/null | sort -n

دایرکتوری‌هایی که عدد بزرگ‌تری دارند، فایل و Directory بیشتری دارند.

مثلاً اگر /var مشکوک بود:

sudo du --inodes -x -d 1 /var 2>/dev/null | sort -n

سپس مرحله‌به‌مرحله وارد مسیر پرمصرف شوید:

sudo du --inodes -x -d 1 /var/lib 2>/dev/null | sort -n

روش دیگر: شمارش فایل‌ها با find

اگر می‌خواهید تعداد فایل یک مسیر را تقریباً بشمارید:

sudo find /var -xdev -type f | wc -l

برای Directoryها:

sudo find /var -xdev -type d | wc -l

گزینه -xdev باعث می‌شود find وارد فایل‌سیستم‌های Mount‌شده دیگر نشود.

چه مسیرهایی معمولاً inode را تمام می‌کنند؟

مثال: بررسی inode مصرف‌شده در /var

sudo du --inodes -x -d 1 /var 2>/dev/null | sort -nr | head -n 20

اگر خروجی نشان داد /var/lib بیشترین inode را دارد:

sudo du --inodes -x -d 1 /var/lib 2>/dev/null | sort -nr | head -n 20

همین روند را ادامه دهید تا مسیر اصلی تولیدکننده فایل‌ها را پیدا کنید.

Docker و مصرف inode

Docker می‌تواند در پروژه‌هایی که Container، Layer، Cache یا فایل‌های بسیار زیادی تولید می‌کنند inode زیادی مصرف کند.

وضعیت Docker را بررسی کنید:

docker system df

و inode زیر مسیر Docker:

sudo du --inodes -x -d 2 /var/lib/docker 2>/dev/null | sort -nr | head -n 30

پاک‌سازی امن Docker

ابتدا ببینید چه چیزی قابل پاک‌سازی است:

docker system df

Containerهای متوقف‌شده:

docker container prune

Imageهای بدون استفاده:

docker image prune

Build Cache:

docker builder prune

Session Fileهای PHP

یکی از علت‌های رایج inode بالا روی Web Serverها Session Fileهای بسیار زیاد است.

مسیر Session را پیدا کنید:

php -i | grep session.save_path

روی بعضی توزیع‌ها ممکن است مسیر مشابه زیر باشد:

/var/lib/php/sessions

تعداد فایل‌ها را بررسی کنید:

sudo find /var/lib/php/sessions -type f | wc -l

Logهای کوچک و زیاد

گاهی مشکل حجم Log نیست؛ مشکل تعداد Log Fileها است.

بررسی:

sudo du --inodes -x -d 2 /var/log 2>/dev/null | sort -nr | head -n 30

همچنین Logrotate را بررسی کنید:

sudo logrotate -d /etc/logrotate.conf

گزینه -d فقط حالت Debug دارد و تغییر واقعی اعمال نمی‌کند.

Cacheهای Application را پیدا کنید

اگر Application پوشه Cache اختصاصی دارد، تعداد Fileها را بررسی کنید.

مثال عمومی:

sudo find /path/to/cache -xdev -type f | wc -l

اگر صدها هزار یا میلیون‌ها فایل وجود دارد، قبل از حذف بررسی کنید Application چه سیاستی برای Cache Expiration دارد.

چطور فایل‌های قدیمی را امن‌تر پیدا کنیم؟

به‌جای Delete فوری، ابتدا فقط فایل‌ها را List کنید.

مثلاً فایل‌های بیش از ۳۰ روز:

sudo find /path/to/cache -xdev -type f -mtime +30 | head -n 100

اگر مطمئن شدید این فایل‌ها قابل حذف‌اند، سپس Cleanup را طراحی کنید.

بعد از پاک‌سازی inode را دوباره بررسی کنید

df -i
df -h

اگر IFree دوباره افزایش پیدا کرده باشد، باید بتوانید فایل جدید بسازید.

تست:

touch /tmp/inode-test
ls -l /tmp/inode-test
rm /tmp/inode-test

اگر inode هنوز 100% است

اگر فایل حذف کرده‌اید ولی df -i تغییر چندانی نکرده، چند احتمال وجود دارد:

No Space Left همیشه inode نیست

اگر df -i inode آزاد زیادی دارد، علت دیگری را بررسی کنید.

سناریوهای مهم:

بررسی Mount Point درست

گاهی df -h / فضای خالی دارد اما Application روی Mount Point دیگری می‌نویسد.

برای مسیر واقعی برنامه:

df -h /var/lib/docker
df -i /var/lib/docker

یا:

df -h /var/www
df -i /var/www

جدول تشخیص سریع No Space Left

چطور از تکرار مشکل جلوگیری کنیم؟

Monitoring ساده inode

برای مشاهده سریع:

df -i

GNU Coreutils همچنین امکان نمایش مستقیم درصد Block و inode را با Output سفارشی فراهم می‌کند. :chatgpt-content-reference{index=”4″}

df --output=target,pcent,ipcent

با این خروجی می‌توانید هم درصد فضای مصرفی و هم درصد inode را کنار هم ببینید.

پرسش‌های متداول

چرا با وجود فضای خالی No Space Left on Device می‌گیرم؟

یکی از علت‌های رایج تمام‌شدن inode است. در این حالت Blockهای دیسک هنوز آزاد هستند اما فایل‌سیستم دیگر inode خالی برای ایجاد فایل جدید ندارد.

چطور inode را بررسی کنیم؟

با دستور df -i. اگر ستون IUse% نزدیک 100% باشد، inode فایل‌سیستم تقریباً تمام شده است.

آیا حذف یک فایل 10GB inode زیادی آزاد می‌کند؟

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

چطور بفهمیم کدام Directory inode زیادی مصرف کرده؟

از du –inodes استفاده کنید و مسیرها را مرحله‌به‌مرحله بررسی کنید. این گزینه برای پیدا کردن Directoryهایی که تعداد فایل زیادی دارند مناسب است.

آیا Docker می‌تواند inode را تمام کند؟

بله. Layerها، Build Cache و فایل‌های تولیدشده داخل Containerها می‌توانند تعداد زیادی inode مصرف کنند. مسیر /var/lib/docker و خروجی docker system df را بررسی کنید.

آیا rm -rf راه‌حل مناسبی است؟

فقط زمانی که دقیقاً می‌دانید فایل‌ها متعلق به چه سرویس یا Cache‌ای هستند. حذف کورکورانه فایل‌های Production می‌تواند Application یا دیتابیس را خراب کند.

منابع رسمی

🔹 GNU Coreutils؛ df و بررسی inode

🔹 GNU Coreutils؛ du –inodes