مقدمه

یکی از مشکلات رایج در مدیریت سرورهای لینوکسی این است که فایل‌های حجیم را حذف می‌کنید، اما خروجی دستور df -h همچنان نشان می‌دهد فضای دیسک پر است و فضای آزاد افزایش پیدا نکرده است.

این مشکل معمولاً به دلیل یکی از موارد زیر رخ می‌دهد:

• فایل حذف شده اما هنوز توسط یک Process باز است.
• فضای زیادی توسط Logها مصرف شده است.
• Inodeهای فایل‌سیستم پر شده‌اند.
• بخشی از فضای ext4 برای کاربر root رزرو شده است.
• فایل‌ها روی Mount Point دیگری قرار دارند.
• Docker، OverlayFS یا Containerها فضای زیادی مصرف کرده‌اند.
• Snapshot یا Backup محلی فضای Disk را اشغال کرده است.
• اختلافی بین خروجی df و du وجود دارد.

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

پیش‌نیازها

• دسترسی SSH به سرور
• دسترسی کاربر root یا sudo
• آشنایی اولیه با ترمینال Linux
• دسترسی به ابزارهایی مانند df، du، lsof و find

بررسی وضعیت کلی فضای دیسک

اولین دستور برای بررسی Disk Usage:

df -h

نمونه:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        80G   76G  4.0G  95% /

در این مثال، پارتیشن / حدود 95 درصد پر شده است.

مشاهده File System Type

برای مشاهده نوع فایل‌سیستم:

df -Th

نمونه:

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda1      ext4   80G   76G  4.0G  95% /

نوع File System در عیب‌یابی برخی مشکلات، مانند Reserved Blocks، اهمیت دارد.

بررسی مصرف واقعی Directoryها

برای مشاهده حجم Directoryهای اصلی:

du -xhd1 /

نمونه:

12G    /var
8G     /home
4G     /usr
1G     /root

گزینه:

-x

باعث می‌شود du از File System اصلی خارج نشود.

مرتب کردن Directoryها بر اساس حجم

برای پیدا کردن بزرگ‌ترین Directoryها:

du -xhd1 / | sort -h

یا برای /var:

du -xhd1 /var | sort -h

پیدا کردن بزرگ‌ترین فایل‌ها

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

find / -xdev -type f -size +1G -exec ls -lh {} \; 2>/dev/null

این دستور فایل‌های بزرگ‌تر از 1GB را نمایش می‌دهد.

پیدا کردن 20 فایل بزرگ سیستم

find / -xdev -type f -printf '%s %p\n' 2>/dev/null |
sort -nr |
head -20

برای خروجی خواناتر:

du -ahx / 2>/dev/null |
sort -rh |
head -20

مهم‌ترین مشکل؛ فایل حذف شده ولی هنوز باز است

یکی از شایع‌ترین دلایلی که باعث می‌شود فضای Disk پس از حذف فایل آزاد نشود، باز بودن فایل توسط یک Process است.

در Linux زمانی که فایل حذف می‌شود ولی Process هنوز File Descriptor آن را باز نگه داشته است، فضای فایل تا زمانی که Process بسته نشود آزاد نخواهد شد.

پیدا کردن فایل‌های حذف‌شده ولی باز

دستور:

lsof +L1

یا:

lsof | grep deleted

نمونه:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK NAME
httpd    2456 root   12w  REG  8,1    8G       0     /var/log/httpd/access_log (deleted)

در این مثال فایل Log حذف شده، اما Process مربوط به httpd همچنان آن را باز نگه داشته است.

فضای 8GB هنوز آزاد نشده است.

مشاهده فایل حذف‌شده یک Process

فرض کنید PID برابر است با:

2456

بررسی کنید:

ls -l /proc/2456/fd

ممکن است خروجی مشابه زیر مشاهده کنید:

12 -> /var/log/httpd/access_log (deleted)

آزاد کردن فضای فایل حذف‌شده

روش امن‌تر معمولاً Restart کردن سرویس مربوطه است.

برای مثال Apache:

systemctl restart httpd

در Ubuntu:

systemctl restart apache2

برای Nginx:

systemctl restart nginx

بعد دوباره بررسی کنید:

df -h

فضا باید آزاد شده باشد.

بررسی Process قبل از Restart

قبل از Restart کردن Process:

ps -fp 2456

یا:

ps aux | grep 2456

ابتدا مطمئن شوید PID مربوط به چه سرویس یا برنامه‌ای است.

چرا rm فایل را حذف می‌کند ولی فضا آزاد نمی‌شود؟

دستور:

rm large.log

فقط Directory Entry فایل را حذف می‌کند.

اگر Process همچنان فایل را باز داشته باشد، Kernel تا زمان بسته شدن File Descriptor فضای آن را نگه می‌دارد.

به همین دلیل:

du

ممکن است حجم را دیگر نشان ندهد، ولی:

df

همچنان Disk Usage بالا را نمایش دهد.

تفاوت df و du

یکی از نشانه‌های مهم این مشکل تفاوت زیاد بین:

df -h

و:

du -sh /

است.

برای مثال:

df:
Used = 90 GB

du:
Used = 55 GB

اختلاف زیاد معمولاً می‌تواند ناشی از موارد زیر باشد:

• Deleted Open Files
• Mount Pointهای مخفی
• Reserved Blocks
• Snapshotها
• فایل‌های خارج از دید فعلی du

بررسی Logها

یکی از رایج‌ترین مصرف‌کنندگان Disk:

/var/log

است.

بررسی کنید:

du -sh /var/log

سپس:

du -h /var/log/* | sort -h

پیدا کردن بزرگ‌ترین Logها

find /var/log -type f -exec du -h {} + | sort -rh | head -20

نمونه:

12G /var/log/messages
8G  /var/log/secure
4G  /var/log/nginx/access.log

خالی کردن Log بدون حذف فایل

اگر یک Log بسیار بزرگ شده است، به‌جای حذف مستقیم فایل می‌توانید آن را خالی کنید:

truncate -s 0 /var/log/messages

یا:

: > /var/log/messages

این روش باعث می‌شود فایل باقی بماند ولی محتوای آن حذف شود.

چرا حذف Log با rm همیشه مناسب نیست؟

اگر اجرا کنید:

rm /var/log/messages

ممکن است Process همچنان File Descriptor قبلی را باز نگه دارد.

در نتیجه Disk Space آزاد نمی‌شود.

برای Logهای فعال معمولاً استفاده از:

truncate

یا Logrotate روش مناسب‌تری است.

بررسی journalctl

در سیستم‌های مبتنی بر systemd، Journal می‌تواند فضای زیادی مصرف کند.

بررسی:

journalctl --disk-usage

نمونه:

Archived and active journals take up 6.5G in the file system.

کاهش حجم systemd Journal

برای نگه داشتن حداکثر 1GB:

journalctl --vacuum-size=1G

یا حذف Logهای قدیمی‌تر از 7 روز:

journalctl --vacuum-time=7d

تنظیم دائمی حجم Journal

فایل زیر را ویرایش کنید:

nano /etc/systemd/journald.conf

برای مثال:

SystemMaxUse=1G

سپس:

systemctl restart systemd-journald

بررسی Logrotate

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

cat /etc/logrotate.conf

و تنظیمات سرویس‌ها:

ls /etc/logrotate.d/

برای اجرای دستی تست:

logrotate -d /etc/logrotate.conf

برای اجرای اجباری:

logrotate -f /etc/logrotate.conf

بررسی Inode

ممکن است Disk فضای خالی داشته باشد اما هیچ فایل جدیدی نتوانید ایجاد کنید.

در این حالت Inodeها را بررسی کنید:

df -i

نمونه:

Filesystem      Inodes   IUsed   IFree IUse%
/dev/sda1      5000000 5000000       0  100% /

در این حالت Disk از نظر حجم ممکن است خالی باشد ولی Inodeها کاملاً مصرف شده‌اند.

Inode چیست؟

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

بنابراین میلیون‌ها فایل کوچک می‌توانند Inodeها را پر کنند، حتی اگر فضای زیادی روی Disk مصرف نشده باشد.

پیدا کردن Directoryهای دارای فایل زیاد

برای شمارش فایل‌ها:

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

برای بررسی تعداد فایل‌ها در Directoryهای مختلف:

for d in /var/*; do
    echo -n "$d: "
    find "$d" -xdev | wc -l
done

محل‌های رایج مصرف Inode

معمولاً این مسیرها را بررسی کنید:

/tmp
/var/tmp
/var/spool
/var/cache
/var/lib/php/sessions
/home/*/mail

همچنین سایت‌هایی که Cache یا Session بسیار زیادی ایجاد می‌کنند.

Reserved Blocks در ext4

در فایل‌سیستم ext4 بخشی از فضای Disk معمولاً برای root رزرو می‌شود.

برای مشاهده:

tune2fs -l /dev/sda1 | grep -i reserved

نمونه:

Reserved block count: 1048576

این فضای رزرو شده برای جلوگیری از مشکلات شدید در زمان پر شدن Disk استفاده می‌شود.

مشاهده درصد Reserved Blocks

tune2fs -l /dev/sda1 | grep -E 'Block count|Reserved block count'

در فایل‌سیستم‌های بزرگ، Reserved Space ممکن است چندین گیگابایت باشد.

کاهش Reserved Blocks

برای مثال تنظیم Reserve روی 1 درصد:

tune2fs -m 1 /dev/sda1

هشدار: این کار را بدون بررسی نوع File System و کاربرد سرور انجام ندهید. روی Root File System وجود مقداری Reserved Space مفید است.

Reserved Blocks و تفاوت df و du

اگر File System از نوع ext4 باشد:

df -Th

و اختلاف کمی بین df و du مشاهده می‌کنید، Reserved Blocks می‌تواند بخشی از علت باشد.

اما اختلاف بسیار زیاد معمولاً بیشتر به Deleted Open Files یا Mount Pointها مربوط است.

بررسی Mount Pointها

برای مشاهده Mountها:

findmnt

یا:

mount

همچنین:

df -hT

فایل مخفی زیر Mount Point

فرض کنید Directory زیر دارید:

/backup

و قبل از Mount کردن Disk دوم، چند صد گیگابایت فایل داخل آن کپی شده است.

سپس Disk دیگری روی:

/backup

Mount شده است.

فایل‌های قبلی هنوز روی Root Disk هستند ولی به دلیل Mount جدید دیده نمی‌شوند.

تشخیص فایل‌های مخفی زیر Mount

ابتدا:

findmnt /backup

اگر /backup Mount Point است، باید با احتیاط آن را Unmount کنید تا محتوای زیرین دیده شود.

برای مثال:

umount /backup

سپس:

du -sh /backup

روی سرور Production قبل از Unmount مطمئن شوید سرویس فعالی از آن Mount استفاده نمی‌کند.

بررسی Processهای استفاده‌کننده از Mount

قبل از Unmount:

lsof +D /backup

یا:

fuser -vm /backup

بررسی Docker

Docker می‌تواند حجم زیادی از Disk را مصرف کند.

بررسی:

docker system df

نمونه:

TYPE            TOTAL     ACTIVE    SIZE
Images          24        7         18GB
Containers      12        8         4GB
Local Volumes   20        10        30GB
Build Cache                         8GB

بررسی مسیر Docker

معمولاً:

/var/lib/docker

را بررسی کنید:

du -sh /var/lib/docker

پاکسازی منابع استفاده‌نشده Docker

برای بررسی ابتدا:

docker system df

سپس در صورت اطمینان:

docker system prune

برای پاکسازی Imageهای استفاده‌نشده نیز:

docker image prune -a

قبل از استفاده از گزینه‌های Cleanup مطمئن شوید Image، Volume یا Container موردنیاز حذف نمی‌شود.

بررسی Docker Volumeها

docker volume ls

و:

docker system df -v

Volumeهای حجیم ممکن است حتی بعد از حذف Container باقی بمانند.

بررسی OverlayFS

برای مشاهده:

df -hT | grep overlay

در سرورهای Docker ممکن است Mountهای overlay زیاد مشاهده شوند.

حذف مستقیم فایل‌های داخل:

/var/lib/docker/overlay2

توصیه نمی‌شود.

مدیریت فضا را از طریق خود Docker انجام دهید.

بررسی Backupهای محلی

یکی دیگر از دلایل پر شدن Disk ذخیره Backup روی همان سرور است.

مسیرهای رایج:

/backup
/backups
/home/backup
/var/backups

بررسی:

du -sh /backup

یا:

du -sh /var/backups

پیدا کردن فایل‌های Backup حجیم

find / -xdev \( -name "*.tar.gz" -o -name "*.zip" -o -name "*.sql" \) -size +500M -ls 2>/dev/null

بررسی cPanel Backup

در سرورهای cPanel معمولاً مسیر زیر را بررسی کنید:

du -sh /backup

یا مسیر تنظیم‌شده در WHM Backup Configuration.

بررسی JetBackup

اگر JetBackup روی Local Destination ذخیره می‌کند، Destination را بررسی کنید.

برای پیدا کردن حجم:

du -sh /path/to/jetbackup

همچنین Retention و Cleanup Jobهای JetBackup را بررسی کنید.

بررسی فایل‌های Temporary

مسیرهای زیر را بررسی کنید:

du -sh /tmp

du -sh /var/tmp

و:

find /tmp -type f -size +500M -ls

پاکسازی فایل‌های قدیمی /tmp

برای مثال فایل‌های قدیمی‌تر از 7 روز:

find /tmp -type f -mtime +7 -print

ابتدا فقط لیست را بررسی کنید.

در صورت اطمینان:

find /tmp -type f -mtime +7 -delete

بررسی Cache Package Manager

در Ubuntu/Debian:

du -sh /var/cache/apt

پاکسازی:

apt clean

در AlmaLinux/Rocky/CentOS:

du -sh /var/cache/dnf

پاکسازی:

dnf clean all

در CentOS 7:

yum clean all

بررسی Core Dump

Core Dumpها ممکن است بسیار حجیم باشند.

بررسی:

find / -xdev -type f -name "core*" -size +100M -ls 2>/dev/null

در systemd:

coredumpctl list

بررسی فضای مصرف‌شده توسط Snap

در Ubuntu:

du -sh /var/lib/snapd

همچنین:

snap list --all

نسخه‌های قدیمی Snap ممکن است فضای زیادی اشغال کنند.

بررسی LVM Snapshot

اگر از LVM استفاده می‌کنید:

lvs

یا:

lvdisplay

Snapshotها نیز می‌توانند فضای Storage Pool را مصرف کنند.

بررسی Deleted Files با حجم بالا

برای خروجی دقیق‌تر:

lsof +L1 | sort -k7 -n

یا:

lsof +L1 | awk '{print $7,$1,$2,$9}' | sort -n

هدف پیدا کردن فایل‌های Deleted با SIZE/OFF بالا است.

آیا Kill کردن Process لازم است؟

خیر، همیشه نه.

اول ترجیح دهید Service را به‌صورت استاندارد Restart یا Reload کنید.

برای مثال:

systemctl restart nginx

به‌جای:

kill -9 PID

استفاده از:

kill -9

باید آخرین گزینه باشد.

بررسی فضای واقعی Root Partition

برای بررسی فقط /:

df -h /

همچنین:

du -xsh /

اگر اختلاف بین این دو بسیار زیاد است:

df = 95 GB
du = 55 GB

ابتدا:

lsof +L1

را بررسی کنید.

این یکی از سریع‌ترین روش‌های تشخیص مشکل است.

سناریوی عملی؛ فایل Log حذف شده ولی Disk هنوز پر است

فرض کنید:

df -h

نمایش می‌دهد:

/dev/sda1   100G   95G   5G   95% /

اما:

du -xsh /

نمایش می‌دهد:

60G /

حدود 35GB اختلاف وجود دارد.

اجرا کنید:

lsof +L1

خروجی:

mysqld  2100 mysql  15w REG 8,1 32212254720 0 /var/log/mysql.log (deleted)

یعنی Process MySQL یک فایل حذف‌شده 30GB را باز نگه داشته است.

ابتدا سرویس را بررسی کنید:

systemctl status mysqld

سپس در Maintenance Window مناسب:

systemctl restart mysqld

دوباره:

df -h

را بررسی کنید.

فضای 30GB باید آزاد شده باشد.

سناریوی عملی؛ df پر است ولی du چیزی نشان نمی‌دهد

مراحل پیشنهادی:

df -h

سپس:

du -xhd1 /

اگر اختلاف زیاد بود:

lsof +L1

اگر چیزی پیدا نشد:

findmnt

سپس Mount Pointهای مشکوک را بررسی کنید.

همچنین:

df -i

و در ext4:

tune2fs -l /dev/sda1 | grep -i reserved

را بررسی کنید.

ترتیب صحیح عیب‌یابی Disk

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

df -h
   ↓
df -i
   ↓
du -xhd1 /
   ↓
lsof +L1
   ↓
/var/log
   ↓
findmnt
   ↓
Docker / Backup / Snapshot
   ↓
Reserved Blocks

دستورات مهم بررسی فضای دیسک

تفاوت df و du

اگر اختلاف زیادی بین df و du وجود دارد، معمولاً باید بررسی عمیق‌تری انجام دهید.

خطاهای رایج

No space left on device

ابتدا:

df -h

و سپس:

df -i

را بررسی کنید.

ممکن است Disk یا Inode پر شده باشد.

فایل حذف شده ولی فضای Disk آزاد نشد

اجرا کنید:

lsof +L1

احتمالاً یک Process همچنان فایل را باز نگه داشته است.

df فضای زیادی نشان می‌دهد ولی du نه

موارد زیر را بررسی کنید:

lsof +L1

findmnt

df -i

همچنین Reserved Blocks و Snapshotها را بررسی کنید.

/var/log بسیار بزرگ شده است

بررسی:

du -h /var/log/* | sort -h

سپس Logrotate، Journal و Application Logها را بررسی کنید.

Disk فضای خالی دارد ولی فایل ایجاد نمی‌شود

بررسی:

df -i

احتمالاً Inodeها تمام شده‌اند.

Docker فضای زیادی گرفته است

بررسی:

docker system df

و:

du -sh /var/lib/docker

قبل از Cleanup مطمئن شوید Resources موردنیاز حذف نمی‌شوند.

بعد از Restart سرویس فضا آزاد شد

این معمولاً نشان می‌دهد یک فایل Deleted توسط Process باز نگه داشته شده بوده است.

برای اطمینان:

lsof +L1

را قبل و بعد از Restart مقایسه کنید.

بهترین روش‌ها

• مصرف Disk را به‌صورت دائمی مانیتور کنید.
• برای 80 یا 85 درصد Disk Usage Alert تعریف کنید.
• Inode Usage را نیز مانیتور کنید.
• Logrotate را برای Logهای حجیم فعال کنید.
• فایل Log فعال را مستقیماً با rm حذف نکنید.
• از lsof +L1 برای بررسی Deleted Open Files استفاده کنید.
• Backupهای قدیمی را طبق Retention Policy مدیریت کنید.
• Storage مربوط به Docker را دوره‌ای بررسی کنید.
• Journal Size را محدود کنید.
• فایل‌های Temporary را دوره‌ای بررسی کنید.
• قبل از حذف فایل حجیم مطمئن شوید Service مربوطه چگونه Log را مدیریت می‌کند.
• حداقل 10 تا 20 درصد فضای امن روی File Systemهای مهم نگه دارید.

اشتباهات رایج

• حذف سریع فایل‌های /var/log با rm
• Restart کردن تصادفی Processها بدون شناسایی آن‌ها
• استفاده از kill -9 به‌عنوان اولین راه‌حل
• بررسی نکردن Inode
• توجه نکردن به Docker Volumeها
• حذف دستی فایل‌های /var/lib/docker
• حذف Backup بدون بررسی Retention
• نادیده گرفتن اختلاف بین df و du
• کاهش Reserved Blocks بدون بررسی
• Unmount کردن Storage فعال بدون بررسی Processها
• پاکسازی /tmp بدون بررسی فایل‌های در حال استفاده

چک‌لیست

پس از مطالعه این مقاله باید بتوانید:

• فضای Disk را با df بررسی کنید.
• Directoryهای حجیم را با du پیدا کنید.
• فایل‌های بزرگ را شناسایی کنید.
• اختلاف df و du را تحلیل کنید.
• Deleted Open Files را پیدا کنید.
• فضای فایل‌های حذف‌شده را آزاد کنید.
• Logهای حجیم را بررسی کنید.
• Systemd Journal را مدیریت کنید.
• Inode Usage را بررسی کنید.
• Reserved Blocks را تشخیص دهید.
• Mount Pointهای مخفی را بررسی کنید.
• مصرف Docker را تحلیل کنید.
• Backupها و Snapshotها را بررسی کنید.
• علت خطای No space left on device را پیدا کنید.

مطالعات بیشتر و منابع رسمی

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

• Linux man page – df
• Linux man page – du
• Linux man page – lsof
• systemd – journalctl Documentation
• Docker – Prune unused objects

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

man df

man du

man lsof

man find

جمع‌بندی

اگر در Linux فایلی را حذف کرده‌اید اما فضای Disk آزاد نشده است، اولین احتمال باید Deleted Open File باشد. در این شرایط Process هنوز File Descriptor فایل حذف‌شده را باز نگه داشته و Kernel نمی‌تواند فضای آن را آزاد کند.

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

lsof +L1

است.

اما مشکل همیشه از فایل‌های حذف‌شده نیست. Logهای حجیم، پر شدن Inode، Reserved Blocks، Mount Pointهای مخفی، Docker، Backupها و Snapshotها نیز می‌توانند باعث شوند فضای Disk برخلاف انتظار آزاد نشود.

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

df -h
   ↓
df -i
   ↓
du -xhd1 /
   ↓
lsof +L1
   ↓
بررسی Logs
   ↓
بررسی Mountها
   ↓
بررسی Docker و Backupها

مهم‌ترین نکته این است که قبل از حذف فایل یا Restart کردن سرویس، ابتدا علت واقعی مصرف Disk را پیدا کنید. در بسیاری از سرورها چند دستور ساده مانند df، du و lsof می‌توانند در چند دقیقه مشخص کنند چرا فضای Disk آزاد نشده است.