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:
1-holat: oz sonli juda katta fayllar
Belgi:
Disk to'lganda troubleshooting maqolasidagi tekshirish tartibiga amal qilib diagnostika qilish:
Sabab darhol va aniq ko'rinadi: bitta fayl fayl tizimidagi deyarli butun band joyni egallagan.
Tuzatish va tekshirish:
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:
1-holatdagi aynan o'sha xato xabari — lekin sabab bir xil deb taxmin qilishdan oldin avval df -h ni tekshiring:
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.
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:
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:
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:
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:
Tekshirish:
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 -hvadu -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)dftomonidan hisoblanadi, lekinduga ko'rinmaydi, chunkidufaqat hali ham katalog daraxtiga bog'langan narsalarni ko'radi.find -delete200 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.lvextenddan keyinresize2fsfayl tizimi allaqachon maksimal hajmda ekani haqida xabar beradi.resize2fsmuvaffaqiyatsiz bo'lgan deb taxmin qilishdan oldinlvextendhaqiqatan hajm oshgani haqida xabar berganini (lvsni qayta ishga tushirib) tasdiqlang. Keng tarqalgan xato —resize2fsni noto'g'ri qurilma yo'liga qarshi ishga tushirish.
Orqaga qaytarish va tozalash
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 -hyetarli bo'lmaganini tushuntirish; - LVM’ga asoslangan fayl tizimini unmount qilmasdan, ishlab turgan holda o'stirish uchun kerak bo'lgan ikkita
lvextend/resize2fsbuyrug'ini aytish.
Mashqlar
- 2-holatni qayta yarating, lekin bu safar fayl tizimini vizual ko'rib chiqish uchun
ncdudan foydalaning (kerak bo'lsa, avval uni o'rnating) vancduning o'zi inode muammosini ochib beradimi yokidf -ihali ham kerakli alohida qadammi, yozib qo'ying. - 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. - 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.