عیب‌یابی کمبود فضای دیسک و inode در لینوکس

lsof فایل‌هایی را نشان می‌دهد که link count آن‌ها کمتر از یک است ولی فرایندی هنوز آن‌ها را باز نگه داشته است. DEVICE و NAME را با فایل‌سیستم هدف تطبیق دهید و PID، FD و inode را ثبت کنید.

عبارت deleted مجوز truncate نیست؛ فایل می‌تواند بخشی از دیتابیس، نگاشت حافظه یا وضعیت قابل بازیابی برنامه باشد. خروجی خالی، نداشتن مجوز و خطای ابزار یک معنا ندارند. SIZE/OFF نیز اندازهٔ منطقی یا offset است، نه اندازهٔ تخصیص واقعی.

sudo lsof -nP +L1

1234 و 5 باید از خروجی همین بررسی آمده باشند. PID و descriptor ممکن است دوباره استفاده شوند؛ درست پیش از بررسی، نام فرایند، زمان شروع، cgroup و inode را تطبیق دهید. environment را بی‌دلیل چاپ نکنید چون ممکن است رمز و توکن داشته باشد.

در خروجی stat، تخصیص برابر blocks ضربدر block_bytes است. موارد تکراری را با دستگاه و inode حذف کنید. snapshot، extent مشترک و حسابداری بومی می‌توانند این مقدار را از فضای فیزیکی واقعاً قابل آزادسازی متفاوت کنند. اگر descriptor ناپدید شد، شناسایی را تکرار کنید؛ عدد تازه را حدس نزنید.

ps -p '1234' -o pid=,ppid=,user=,comm=,lstart=
sudo cat '/proc/1234/cgroup'
sudo lsof -nP -a -p '1234' +L1
sudo stat -L -c 'type=%F device=%d inode=%i size=%s blocks=%b block_bytes=%B links=%h' '/proc/1234/fd/5'

اگر journal سهم مهمی دارد، حسابداری خودش را ببینید. فایل لاگ برنامه و journal یک منبع واحد نیستند.

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

sudo journalctl --disk-usage

بعد از آزادسازی یا افزایش ظرفیت از مسیر مجاز، همان فایل‌سیستم را دوباره اندازه بگیرید. کم‌شدن du بدون افزایش فضای آزاد df می‌تواند نشانهٔ باقی‌ماندن فایل باز باشد.

فضای آزاد به‌تنهایی ثابت نمی‌کند نوشتن برنامه یا تراکنش آن درست شده است. بررسی محدود سلامت و نوشتن/خواندن خود سرویس را هم انجام دهید و موارد حل‌نشده را در گزارش بنویسید.

df -hT -- '/var'
df -i -- '/var'
sudo lsof -nP +L1