Disk to'lganda troubleshooting

"13. Disk, filesystem, LVM va storage" modulida Disklar va block qurilmalar, Bo'limlar (partitions), Fayl tizimi turlari, mount va umount, fstab, LVM, RAID, Swap, LUKS shifrlash, NFS, Disk kvotalari va Disk bandligi (disk usage) alohida mavzular sifatida ko'rib chiqildi. Bu maqola modulning yakunlovchi, amaliy umumlashmasi: u shu bilimlarning hammasini bitta real hodisani — "diskda joy qolmadi" — hal qilishning yagona, izchil tartibiga birlashtiradi.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• "No space left on device" xatosi chiqqanda amal qilinadigan tekshiruv ketma-ketligini eslab qolish;
• df -h va df -i yordamida muammo baytlar tugashidami yoki inode’lar tugashidami, ajratish;
• katta kataloglarni du bilan, o'chirilgan, lekin ochiq turgan fayllarni lsof bilan topish;
• journalctl --vacuum-size va log rotation orqali joy bo'shatish;
• uzoq muddatli yechim sifatida qachon LVM, kvotalar va monitoringga murojaat qilish kerakligini bilish.

Nega "No space left on device" chalkash

Bu xato butunlay turli sabablardan kelib chiqishi mumkin:

• fayl tizimida haqiqatan baytlar tugagan;
• fayl tizimida inode’lar tugagan (baytlar bo'sh, lekin yangi fayl yaratib bo'lmaydi);
• fayl tizimi to'la ko'rinmaydi, lekin o'chirilgan, lekin ochiq turgan fayllar bloklarni band qilib turibdi;
• kvota cheklovi to'lgan (butun fayl tizimi emas, faqat bitta foydalanuvchi yoki guruh).

Har biri boshqa yechimni talab qiladi, shuning uchun buyruqlarni tasodifiy sinab ko'rish o'rniga tizimli tekshiruv tartibi kerak.

Tekshiruv tartibi: umumiy ko'rinish

1. df -h        → which filesystem, and how full
2. df -i        → is it an inode problem, not a byte problem
3. du/ncdu      → which directory/file is responsible
4. lsof         → are there deleted-but-open files
5. clear logs or journalctl --vacuum
6. long-term: LVM extension, quotas, monitoring

Har bir qadam quyida alohida ko'rib chiqiladi, so'ng bitta amaliy vaziyatga birlashtiriladi.

1-qadam: df -h — qaysi fayl tizimi va qanchalik to'la

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   50G     0  100% /

Bu Disk bandligi (disk usage) maqolasida ko'rilgan asosiy vosita — u parametr talab qilmaydi va bir zumda natija beradi. Maqsad — muammoli mount nuqtasini aniq belgilash, chunki keyingi har bir qadam shu katalog ichida ishlaydi.

2-qadam: df -i — baytlar yoki inode muammosi

df -i /

Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/sda1       3276800 3276800      0  100% /

Agar Use% (baytlar) past, IUse% (inode’lar) esa 100% bo'lsa, muammo butunlay boshqacha: baytlar bo'sh bo'lsa ham inode’lar tugagani uchun yangi fayl yaratib bo'lmaydi. Bunday holatda du bilan katta fayl qidirish ma’nosiz — buning o'rniga millionlab mayda fayl yaratayotgan narsani toping (masalan, sessiyalar katalogi yoki noto'g'ri sozlangan kesh):

find / -xdev -printf '%h\n' | sort | uniq -c | sort -rn | head

Bu buyruq har bir katalogdagi fayllar sonini sanaydi va eng ko'p fayl saqlayotgan kataloglarni ro'yxatlaydi.

3-qadam: du/ncdu — katta kataloglarni topish

Agar baytlar tugagan bo'lsa, keyingi qadam — Disk bandligi (disk usage) maqolasida ko'rilgan usullar:

sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head

Yoki interaktiv:

sudo ncdu /

Maqsad — bosqichma-bosqich pastga tushib, aybdor katalog yoki faylni topish.

4-qadam: lsof — o'chirilgan, lekin ochiq turgan fayllar

Agar du dan chiqqan yig'indi df ko'rsatgan "ishlatilgan" hajmdan sezilarli kam bo'lsa, sabab deyarli har doim o'chirilgan, lekin ochiq turgan fayllar (Disk bandligi (disk usage) maqolasida tushuntirilgan). Ularni topish uchun lsof ishlatiladi:

sudo lsof +L1

+L1 link soni 1 dan kichik bo'lgan fayllarni ko'rsatadi — ya’ni fayl allaqachon fayl tizimidan olib tashlangan, lekin biror jarayon uni hali ham ochiq ushlab turibdi.

COMMAND   PID   USER   FD   TYPE DEVICE  SIZE/OFF NLINK    NODE NAME
nginx    1234    www   13w   REG    8,1  28000000     0  123456 /var/log/nginx/access.log (deleted)

NLINK qiymatining 0 ekani va nom oxiridagi (deleted) fayl allaqachon o'chirilganini, lekin nginx jarayoni (PID 1234) uni hali ham fayl deskriptori orqali ochiq ushlab turganini bildiradi — shuning uchun 28 MB disk bloklari hali ham band.

Muqobil sifatida grep bilan:

sudo lsof | grep deleted

Joy bo'shatish: jarayonni qayta ishga tushirish

O'chirilgan, lekin ochiq turgan fayldan joy bo'shatishning eng ishonchli usuli — uni ushlab turgan jarayonni qayta ishga tushirish (bu fayl deskriptorini yopadi va bloklarni avtomatik bo'shatadi):

sudo systemctl restart nginx

Agar xizmatni darhol qayta ishga tushirib bo'lmasa, muqobil — jarayonni fayl mazmunini yopishga majburlash (ehtiyotkorlik bilan, faqat yaxshi tushunilgan vaziyatda):

: > /proc/1234/fd/13

Bu faylni o'chirmaydi — faqat uning mazmunini tozalaydi; deskriptor ochiq qoladi, lekin band bloklar bo'shatiladi.

5-qadam: log fayllarini tozalash

Ko'p hollarda disk to'lishining eng keng tarqalgan sababi — nazoratsiz, doimiy o'sib boradigan log fayli.

journalctl --vacuum-size

systemd-journald log'lari vaqt o'tishi bilan kattalashishi mumkin. Joriy hajmni tekshirish:

journalctl --disk-usage

Uni berilgan hajmgacha qisqartirish:

sudo journalctl --vacuum-size=200M

Yoki berilgan muddatdan eski yozuvlarni olib tashlash:

sudo journalctl --vacuum-time=7d

Doimiy log rotation

Bir martalik tozalash sababni emas, belgini davolaydi. Uzoq muddatli yechim — logrotate konfiguratsiyasi haqiqatan ishlayotganini tasdiqlash:

cat /etc/logrotate.d/nginx
sudo logrotate -f /etc/logrotate.d/nginx

-f (force) — rotation’ni jadvaldan qat’i nazar darhol ishga tushiradi. Agar log rotation allaqachon sozlangan bo'lsa-yu, hajm baribir nazoratsiz o'sgan bo'lsa, sabab ko'pincha aynan yuqorida ko'rilgan "o'chirilgan, lekin ochiq turgan fayl" muammosi: logrotate eski faylni almashtirgan, lekin xizmat logrotate konfiguratsiyasidagi postrotate bloki orqali qayta ishga tushirilmagani yoki signal (SIGHUP yoki restart) olmagani uchun eski fayl deskriptoriga yozishda davom etgan.

6-qadam: uzoq muddatli yechimlar

Vaziyat hal bo'lgach, xuddi shu muammo takrorlanmasligi uchun:

• LVM orqali kengaytirish — agar VG'da bo'sh joy bo'lsa, LVM: hajmni o'zgartirish va snapshot maqolasida ko'rilgan lvextend -r yordamida bo'limni umuman qayta bo'limlamasdan kattalashtirish mumkin;
• Disk kvotalari — agar muammo bitta foydalanuvchi yoki xizmatning cheksiz o'sishidan kelib chiqqan bo'lsa, Disk kvotalari maqolasida ko'rilgan usrquota/grpquota orqali cheklov o'rnatish takrorlanishning oldini oladi;
• Monitoring va ogohlantirish — disk bandligi chegaradan (masalan, 80%) oshganda avtomatik ogohlantiradigan monitoring (Prometheus + Alertmanager, Zabbix yoki oddiy cron skripti) sozlash muammo "disk 100% to'la" holatiga yetishidan ancha oldin ushlanishini ta’minlaydi.

Amaliy vaziyat: production serverda /var to'lib qoldi

Vaziyat: monitoring ogohlantirish yubordi — veb-server 500 xatolarini qaytaryapti, ilova log'larida esa "No space left on device" ko'rinyapti. Server production, shuning uchun har bir tekshiruv dastlab faqat o'qish rejimida bajariladi.

1-qadam. Umumiy holatni aniqlang.

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/vg_data/lv_var  20G   20G     0 100% /var

/var o'zining alohida LV’sida turibdi (LVM asoslari maqolasida ko'rilgan o'sha andoza) va u butunlay to'la.

2-qadam. Inode’lar tugaganmi-yo'qmi, tekshiring.

df -i /var

Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/vg_data/lv_var  1310720  85000 1225720    7% /var

Inode’lar 7% da — muammo inode’larda emas, baytlarda. Keyingi qadam — katta faylni topish.

3-qadam. Javobgar katalogni toping.

sudo du -h --max-depth=1 /var | sort -rh | head

19G     /var/log
600M    /var/lib

sudo du -h --max-depth=1 /var/log | sort -rh | head

18G     /var/log/app

sudo du -ah /var/log/app | sort -rh | head -3

17G    /var/log/app/error.log

4-qadam. Faylni tekshiring — u haqiqatan 17 GiB mi yoki du allaqachon o'chirilgan faylni sanay olmayaptimi?

ls -lh /var/log/app/error.log

-rw-r--r-- 1 appuser appuser 17G Jul 25 09:12 /var/log/app/error.log

Fayl haqiqatan mavjud va 17 GiB. Sababni oxirgi qatorlar bilan tekshirish:

sudo tail -n 20 /var/log/app/error.log

Natija bir xil xato xabari minglab marta takrorlanganini ko'rsatadi — ilova to'g'ri hal qila olmaydigan xatoni log'ga yozib, cheksiz siklda qayta urinmoqda. logrotate konfiguratsiyasi ham tekshiriladi:

cat /etc/logrotate.d/app

Natija — konfiguratsiya fayli mavjud emas: bu ilovaning log'i hech qachon aylantirilmagan.

5-qadam. Joyni darhol bo'shating — faylni (o'chirmasdan) tozalang va xizmatni qayta ishga tushiring.

sudo truncate -s 0 /var/log/app/error.log
sudo systemctl restart app

truncate -s 0 faylning inode’ini saqlab qoladi (ruxsatlar va egasi o'zgarmaydi), faqat uning mazmunini tozalaydi — bu rm va keyin qayta yaratishdan xavfsizroq, chunki ilovaning hali ochiq turgan yozish deskriptori bilan ziddiyat yaratmaydi.

6-qadam. Natijani tasdiqlang.

df -h /var

Filesystem      Size  Used Avail Use% Mounted on
/dev/vg_data/lv_var  20G   2.1G   17.9G  11% /var

7-qadam. Uzoq muddatli yechim.

• /etc/logrotate.d/app konfiguratsiyasini yarating (kunlik rotation, maxsize 500M, siqish, eski nusxalarni saqlash muddati);
• ilova jamoasini cheksiz xato sikli haqida xabardor qiling (asl sabab; log hajmi faqat belgi);
• disk bandligi 80% chegarasiga yetganda ogohlantiradigan monitoring qo'shing, shunda muammo keyingi safar 100% ga yetishidan oldin ushlanadi.

Xulosa: bitta "disk to'la" ogohlantirishi uchta qatlamni yashirgan edi — darhol ko'rinadigan belgi (/var to'la), oraliq sabab (log rotation yo'q) va asl sabab (ilovadagi xato sikli). Faqat birinchi qatlamni tuzatish (joy bo'shatish) muammoni oxir-oqibat qaytarardi — uchala qatlamni ham hal qilish kerak edi.

Keng tarqalgan xatolar

Sababni aniqlamasdan faylni o'chirish

Katta faylni tekshirmasdan darhol o'chirish xavfli — bu ma’lumot yo'qolishiga yoki keyinchalik kerak bo'ladigan diagnostik ma’lumotni yo'q qilishga olib kelishi mumkin. Avval u nima ekanini va nega shunchalik kattalashganini tushunish kerak.

Faqat df -h ga qarab, df -i ni unutish

Diskda joy bor-u, lekin baribir fayl yozib bo'lmayotgan vaziyatda faqat df -h ga qarab "hammasi joyida" degan xulosaga kelish inode’lar tugashi muammosini butunlay o'tkazib yuboradi.

O'chirilgan, lekin ochiq turgan faylni oddiy rm bilan "tuzatishga" urinish

Agar fayl allaqachon o'chirilgan bo'lsa (lsof +L1 uni ko'rsatadi), unga yana rm qo'llash hech narsani o'zgartirmaydi — jarayon uni ochiq ushlab turar ekan, bloklar band qoladi. Yechim — jarayonni qayta ishga tushirish.

Asl sababni tekshirmasdan faqat belgini davolash

Joy bo'shatilgach, log rotation’ni yoki ilovaning asosiy xatosini tekshirmasdan muammoni "hal bo'ldi" deb hisoblash bir necha kun ichida xuddi shu vaziyatning takrorlanishiga olib keladi.

Mashqlar

1. O'chirib tashlasa bo'ladigan VM’da sun’iy ravishda katta fayl yarating (dd if=/dev/zero of=/tmp/bigfile bs=1M count=2000), uni jarayon bilan ochiq ushlab turing (masalan, tail -f /tmp/bigfile &) va rm /tmp/bigfile ni bajaring — df -h va du -sh /tmp natijalarini solishtiring.
2. Yuqoridagi vaziyatda o'chirilgan, lekin ochiq turgan faylni lsof +L1 bilan toping, uni ushlab turgan jarayonni to'xtating va joy qaytganini tasdiqlang.
3. Joriy journal hajmini journalctl --disk-usage bilan tekshiring, so'ng uni journalctl --vacuum-size=100M bilan qisqartiring.
4. Sinov VM’ida /etc/logrotate.d/ ostida oddiy konfiguratsiya yarating (masalan, /tmp/testapp.log uchun, kunlik, maxsize 10M) va uni logrotate -f bilan majburan ishga tushirib, natijani tekshiring.

Mashqni bajardim deyish uchun: "disk to'la" ogohlantirishi berilganda tekshiruv ketma-ketligini (df -h → df -i → du/ncdu → lsof +L1 → log'larni tozalash → uzoq muddatli yechim) yoddan, tartib bilan ayta olishingiz kerak.

Xulosa

"13. Disk, filesystem, LVM va storage" moduli disklarni tanib olishdan (Disklar va block qurilmalar, lsblk) boshlandi, bo'limlar va fayl tizimlarini yaratish, ularni mount qilish va fstab orqali doimiy ulash, LVM bilan moslashuvchan volume boshqaruvi, RAID va shifrlash orqali ishonchlilik va xavfsizlik, NFS bilan tarmoq orqali ulashish va nihoyat kvotalar hamda disk bandligi orqali joyni nazorat qilish orqali o'tdi. Bu maqola shu bilimlarning hammasini bitta amaliy tartibga birlashtirdi: df -h → df -i → du/ncdu → lsof +L1 → log'larni tozalash → uzoq muddatli LVM/kvota/monitoring yechimi. Bitta "disk to'la" ogohlantirishi ko'pincha ko'p qatlamli muammoni yashiradi, shuning uchun faqat belgini emas, asl sababni topish muhim.

Bu tekshiruv ketma-ketligini har safar qo'lda takrorlash o'rniga uni avtomatlashtirish mumkin — masalan, disk bandligini muntazam tekshirib, chegaradan oshganda ogohlantirish yuboradigan skript yozib. Aynan shunday avtomatlashtirish keyingi "14. Bash scripting" modulining mavzusi: u Bash skript asoslari dan boshlanadi, o'zgaruvchilar, shartlar va sikllar hamda xatolarni qayta ishlash orqali o'tadi va oxir-oqibat diskni kuzatadigan va log'larni tozalaydigan to'liq skript quriladi.

Manbalar

• man7.org: df(1)
• man7.org: du(1)
• man7.org: lsof(8)
• man7.org: journalctl(1)
• man7.org: logrotate(8)
• man7.org: truncate(1)
• Red Hat: disk joyi muammolarini hal qilish
• Ubuntu Server hujjatlari: Loglar