Tarkibga o'tish

Lab: "disk to'la" holatidan doimiy yechimgacha

Disk bandligi (disk usage) va Disk to'lganda troubleshooting maqolalarida df/du va to'lgan fayl tizimini tekshirish tartibi ko'rib chiqilgan edi. Bu lab haqiqiy fayl tizimini ataylab to'ldiradi va ko'zingizga tasodifan birinchi tushgan katta fayl emas, haqiqiy sababni topish uchun to'liq diagnostika ketma-ketligini bosib o'tadi. Keyin aniqlangan cheklovga qarab ikki xil tuzatishni qo'llaydi — haqiqatan to'lgan fayl tizimi yoki inode’lari tugagan fayl tizimi. Chunki to'g'ri tuzatish aynan qaysi biri ekaniga qarab butunlay farq qiladi.

Maqsad va yakuniy natija

Bu lab oxirida siz lab fayl tizimidagi disk joyi bilan bog'liq ikkita mustaqil favqulodda holatni diagnostika qilgan va hal qilgan bo'lasiz: biri oz sonli juda katta fayllar sabab, ikkinchisi juda ko'p mayda fayllar bilan mavjud inode’larni tugatish sabab. Buning uchun faqat standart df/du/find vositalaridan foydalanasiz va har bir vaziyatga aslida qaysi tuzatish kerakligini to'g'ri ajratasiz.

Topologiya va boshlang'ich holat

To'ldirish uchun alohida, ajratilgan fayl tizimi bor bitta lab VM. Loopback orqali mount qilingan image fayldan foydalanish bu labni VM’ingizning haqiqiy root fayl tizimidan to'liq ajratib turadi. Bu diskni mashinaning o'ziga hech qanday xavf tug'dirmasdan 100% gacha to'ldirishni mashq qilishning xavfsiz usuli.

Talablar

  • root yoki sudo huquqi;
  • lab loopback image’ini yaratish uchun hostda taxminan 200 MB bo'sh joy.

Xavfsizlik va snapshot haqida eslatma

Warning

Bu lab fayl tizimini ataylab to'liq to'ldiradi. Buni hech qachon haqiqiy root fayl tizimingizda (/) qilmang. Haqiqatan to'lgan root fayl tizimi tizimga kirishga, sudo ishlashiga va uni tuzatish uchun kerak bo'lgan buyruqlarning o'zi ishga tushishiga to'sqinlik qilishi mumkin. Bu lab aynan xato host uchun hech qanday oqibat keltirmasligi uchun alohida loopback fayl tizimidan foydalanadi.

1-qadam: izolyatsiya qilingan lab fayl tizimini yaratish

sudo mkdir -p /mnt/disklab
sudo dd if=/dev/zero of=/root/disklab.img bs=1M count=200 status=progress
sudo mkfs.ext4 /root/disklab.img
sudo mount -o loop /root/disklab.img /mnt/disklab

dd if=/dev/zero of=/root/disklab.img bs=1M count=200 nol baytlardan iborat 200 MiB’lik fayl yaratadi. mkfs.ext4 uni oddiy ext4 fayl tizimi sifatida formatlaydi, mount -o loop esa o'sha faylni xuddi haqiqiy block qurilmadek mount qiladi. Natijada hostdagi boshqa hech narsaga bog'liq bo'lmagan, to'liq bir martalik, izolyatsiya qilingan 200 MiB’lik disk hosil bo'ladi.

Tekshirish:

df -h /mnt/disklab
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0      193M   1.6M  178M   1% /mnt/disklab

1-holat: oz sonli juda katta fayllar

sudo dd if=/dev/zero of=/mnt/disklab/large-log.bin bs=1M count=150 status=progress

Belgi:

df -h /mnt/disklab
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0      193M   152M   30M   85% /mnt/disklab

Disk to'lganda troubleshooting maqolasidagi tekshirish tartibiga amal qilib diagnostika qilish:

sudo du -h --max-depth=1 /mnt/disklab | sort -rh
152M    /mnt/disklab
150M    /mnt/disklab/large-log.bin

Sabab darhol va aniq ko'rinadi: bitta fayl fayl tizimidagi deyarli butun band joyni egallagan.

Tuzatish va tekshirish:

sudo rm /mnt/disklab/large-log.bin
df -h /mnt/disklab
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0      193M   1.6M  178M   1% /mnt/disklab

2-holat: inode’larning tugashi — joy deyarli bo'sh bo'lsa ham to'la

Ko'pchilik administratorlarni birinchi marta duch kelganda hayron qoldiradigan holat shu: df -h ko'p bo'sh joy borligini ko'rsatishi mumkin, fayl tizimi esa bitta ham yangi fayl yarata olmaydi.

sudo bash -c '
for i in $(seq 1 200000); do
    touch "/mnt/disklab/tinyfile_$i" 2>/dev/null || break
done
'

Belgi:

sudo touch /mnt/disklab/one-more-file.txt
touch: cannot touch '/mnt/disklab/one-more-file.txt': No space left on device

1-holatdagi aynan o'sha xato xabari — lekin sabab bir xil deb taxmin qilishdan oldin avval df -h ni tekshiring:

df -h /mnt/disklab
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0      193M    12M  166M   7% /mnt/disklab

Joyning faqat 7% i band, shunga qaramay fayl tizimi yangi fayl yaratishni rad etyapti. Bu fayl tizimi xom bayt bandligidan mustaqil ravishda tugatishi mumkin bo'lgan boshqa resursni — inode’larni — tekshirish kerakligining kuchli, aniq belgisi.

df -i /mnt/disklab
Filesystem       Inodes  IUsed  IFree IUse% Mounted on
/dev/loop0        12800  12800      0  100%  /mnt/disklab

IUse% 100% buni aniq tasdiqlaydi: bu fayl tizimi formatlanganda ajratilgan har bir inode hozirgina yaratilgan mayda fayllar tomonidan bittadan egallab olingan. Disk to'lganda troubleshooting maqolasida tushuntirilganidek, faylning haqiqiy mazmuni qanchalik kichik bo'lishidan qat’i nazar, uning metama’lumotlarini kuzatish uchun inode kerak. O'z hajmiga nisbatan nisbatan kam inode bilan formatlangan fayl tizimi (oz sonli, katta fayllarni saqlashi kutilgan fayl tizimlarida keng tarqalgan holat) xom joy tugashidan ancha oldin inode’larni tugatishi mumkin.

Tuzatish — fayllarni o'chirish inode’larni bo'shatadi, chunki har bir mayda fayl aynan bittadan inode egallagan edi:

sudo find /mnt/disklab -name "tinyfile_*" -delete
df -i /mnt/disklab
Filesystem       Inodes  IUsed  IFree IUse% Mounted on
/dev/loop0        12800     11  12789    1%  /mnt/disklab

Intervyuda: "df 90% bo'sh deyapti — nega yozish baribir muvaffaqiyatsiz?"

Bu nomzod fayl tizimida ikkita mustaqil, alohida tugashi mumkin bo'lgan resurs — joy va inode’lar — borligini tushunadimi, yo'qmi, bevosita, amaliy tekshiradi. df -h bo'sh joy ko'rsatishiga qaramay "No space left on device" paydo bo'lgan zahoti to'g'ri diagnostika refleksi — darhol df -i. Bu lab ko'rsatganidek, umuman mavjud bo'lmasligi mumkin bo'lgan katta faylni qidirib du ni qayta ishga tushirish emas.

Intervyuda: "df disk to'la deydi, lekin du hech narsa topmaydi — joy qayerga ketdi?"

Bu disk to'lishi bilan bog'liq boshqa klassik kutilmagan savol va uning aniq sababi hamda aniq tuzatishi bor. df fayl tizimini deyarli to'la deb ko'rsatsa-yu, xuddi shu daraxtni aylanib chiqqan du ancha kamroq joyni hisoblasa, joyni deyarli har doim o'chirilgan, lekin hali ham ochiq turgan fayl egallab turadi. Jarayon (ko'pincha log fayli rm qilingan yoki qayta ochish uchun signal berilmasdan rotate qilingan log yozuvchi) hali ham fayl deskriptorini ushlab turadi, shuning uchun kernel ma’lumotlarni diskda saqlaydi. Bu faqat hali ham katalogga bog'langan fayllarni ko'radigan du ga ko'rinmaydi, lekin df tomonidan to'liq hisoblanadi. Diagnostika vositasi du emas, lsof:

sudo lsof +L1        # lists open files whose link count is 0 (deleted but still held open)
COMMAND   PID   USER   FD   TYPE  DEVICE  SIZE/OFF  NLINK  NODE  NAME
rsyslogd  812   root   7w   REG   8,1     4198400000    0   131  /var/log/app.log (deleted)

Tuzatish o'chirish uchun fayl qidirish emas — fayl allaqachon o'chirilgan — balki uni ushlab turgan jarayonni deskriptorni bo'shatishga majbur qilish: uni qayta ishga tushiring (systemctl restart rsyslog) yoki log'larini qayta ochishi uchun signal yuboring va joy darhol qaytariladi. Katta faol log faylda rm yozuvchi servis qayta ishga tushirilmaguncha hech narsani bo'shatmaydigandek ko'rinishining sababi aynan shu.

Amaliy vaziyat: fayl tizimiga haqiqatan ko'proq joy kerak bo'lgandagi doimiy yechim

Muammo. 1 va 2-holatlardan farqli o'laroq, ba’zan fayl tizimi to'g'ri, qonuniy ravishda to'la bo'ladi — o'chiriladigan bitta katta fayl ham, inode sizib chiqishi ham yo'q, ish yuki shunchaki unga berilgan joydan o'sib chiqqan. LVM’ga asoslangan fayl tizimida to'g'ri tuzatish o'chirish uchun biror narsa qidirish emas, uni kengaytirish.

Joriy holatni tekshirish:

sudo vgs
sudo lvs
VG      #PV #LV #SN Attr   VSize  VFree
vg-data   1   1   0 wz--n- 20.00g  5.00g

VFree volume group’da hali ham 5 GiB ajratilmagan joy borligini tasdiqlaydi. Bu uning ichidagi istalgan logical volume’ni kengaytirish uchun zaruriy shart — aynan LVM: hajmni o'zgartirish va snapshot maqolasida ko'rib chiqilganidek.

Buyruq — LV’ni kengaytirish va fayl tizimini unga mos ravishda o'stirish:

sudo lvextend -L +5G /dev/vg-data/lv-app
sudo resize2fs /dev/vg-data/lv-app

Tekshirish:

df -h /mnt/app-data

Natija. Fayl tizimining umumiy hajmi ilova ma’lumotlari buzilmagan holda va hech qanday to'xtashsiz darhol oshadi — LV unmount qilinmasdan, ishlab turgan holda kengaytirildi.

Xulosa. Bu labdagi uchta holat birgalikda "disk to'la" uchun to'liq qaror daraxtini qamrab oladi: o'chiriladigan katta fayl (1-holat), tozalanadigan inode sizib chiqishi (2-holat) yoki — ikkalasi ham to'g'ri kelmaganda — aslida hech qachon muammo bo'lmagan narsani qidirishda davom etish o'rniga lvextend bilan hal qilinadigan qonuniy qo'shimcha joy ehtiyoji.

Troubleshooting bo'yicha maslahatlar

  • df -h va du -sh / bir xil fayl tizimi uchun sezilarli darajada farq qiladigan jami ko'rsatadi. Disk bandligi (disk usage) maqolasida tushuntirilganidek, o'chirilgan, lekin hali ham ochiq turgan fayl (ishlab turgan jarayon ushlab turgan) df tomonidan hisoblanadi, lekin du ga ko'rinmaydi, chunki du faqat hali ham katalog daraxtiga bog'langan narsalarni ko'radi.
  • find -delete 200 000 ta mayda faylga qarshi sekin ishlaydi. Bu kutilgan holat — juda ko'p sonli mayda fayllarni o'chirish xuddi shunday umumiy metama’lumot yukiga ega bitta katta faylni o'chirishdan har bir fayl hisobiga haqiqatan sekinroq. Haqiqiy hodisa paytida tozalash vaqtini baholashda buni bilish foydali.
  • lvextend dan keyin resize2fs fayl tizimi allaqachon maksimal hajmda ekani haqida xabar beradi. resize2fs muvaffaqiyatsiz bo'lgan deb taxmin qilishdan oldin lvextend haqiqatan hajm oshgani haqida xabar berganini (lvs ni qayta ishga tushirib) tasdiqlang. Keng tarqalgan xato — resize2fs ni noto'g'ri qurilma yo'liga qarshi ishga tushirish.

Orqaga qaytarish va tozalash

sudo umount /mnt/disklab
sudo rm -f /root/disklab.img
sudo rmdir /mnt/disklab

Yakuniy baholash mezoni

Siz quyidagilarni yoddan qila olsangiz, bu lab yakunlangan hisoblanadi:

  • joy tugashi sababini inode tugashi sababidan ajratadigan aniq buyruqni aytish;
  • 2-holatni diagnostika qilish uchun nega faqat df -h yetarli bo'lmaganini tushuntirish;
  • LVM’ga asoslangan fayl tizimini unmount qilmasdan, ishlab turgan holda o'stirish uchun kerak bo'lgan ikkita lvextend/resize2fs buyrug'ini aytish.

Mashqlar

  1. 2-holatni qayta yarating, lekin bu safar fayl tizimini vizual ko'rib chiqish uchun ncdu dan foydalaning (kerak bo'lsa, avval uni o'rnating) va ncdu ning o'zi inode muammosini ochib beradimi yoki df -i hali ham kerakli alohida qadammi, yozib qo'ying.
  2. Yangi loopback image’ni mkfs.ext4 -N 500 <image> yordamida ataylab kam inode soni bilan formatlang va bu labdagi standart formatlashga nisbatan inode’lar qanchalik tezroq tugashini kuzating.
  3. XFS fayl tizimlari inode’larni ajratishni ext4 dan nega boshqacha boshqarishini va buning shu labda ko'rsatilgan "inode tugashi" nosozligi uchun qanday amaliy oqibati borligini o'rganib chiqing va qisqa paragrafda tushuntiring.

Manbalar