Disk va fayl tizimi asoslari

/var/log/app.log oddiy yo'lga o'xshaydi, lekin uning nomidan baytlar aslida qayerda saqlanishini bilib bo'lmaydi. Bu yo'l ext4 bilan formatlangan NVMe diskdagi bo'limga, NFS orqali ulashilgan katalogga, operativ xotiradagi tmpfs ga yoki konteynerning overlay qatlamiga olib borishi mumkin. "Disk to'ldi" degan ogohlantirish kelganda administratorning birinchi vazifasi — shu qatlamlarni bir-biridan ajrata bilish.

Bu maqola saqlash qurilmasini faylga bog'laydigan tushunchalar tizimini quradi. Biz unda haqiqiy diskni fdisk/parted bilan bo'limlarga ajratmaymiz va production’dagi /etc/fstab ga tegmaymiz. Bular o'z laboratoriyasi va o'z snapshot’i bilan alohida o'rganiladigan amaliy mavzular (Mount tushunchalari maqolasi mount tomonini yoritadi; bo'limlarga ajratish bo'yicha alohida laboratoriya esa kursda hali yo'q, bu haqda oxirida aytilgan). Maqolaning katta qismi Ubuntu Server LTS’da Bash yordamida faqat mavjud holatni o'qiydi. Faqat bitta bo'limda bir martalik loopback fayllar ustida LVM hajmlari quriladi: shunda zaxira disk talab qilmasdan, bu modelni xavfsiz ko'rsatish mumkin bo'ladi. Fayl va matn qidirish maqolasidagi yo'llar va pipeline’lar bilan ishlash odatlari tanish deb hisoblanadi. Quyida disk, bo'lim, hajm (volume), fayl tizimi va mount nuqtasini bir-biridan ajratishni; kernelning virtual fayl tizimi (VFS) turli fayl tizimlarini bitta interfeys orqali qanday taqdim etishini; yo'l qanday qilib inode’gacha aniqlanishini; lsblk, findmnt, df, du va stat ga qaysi savolni berish kerakligini; LVM, RAID va disk kvotalari bu tuzilmaning qayerida turishini o'rganamiz. Shuningdek, "No space left on device" xatosi uchun faqat o'qish orqali dalil yig'ishni ko'ramiz va blok sig'imi bilan inode sig'imi bir-biridan mustaqil ravishda tugashini yodda tutamiz.

Saqlash qatlamlari bir-birining o'rnini bosmaydi

Soddalashtirilgan lokal saqlash tuzilmasi quyidagicha:

SSD or HDD
  └─ block device: /dev/nvme0n1
       └─ partition: /dev/nvme0n1p2
            └─ file system: ext4
                 └─ mount point: /
                      └─ path: /var/log/app.log

Haqiqiy serverda bo'lim va fayl tizimi orasiga qo'shimcha qatlamlar qo'shilishi mumkin: LUKS shifrlash, dasturiy RAID yoki LVM. Tarmoq fayl tizimida esa umuman lokal blok qurilma bo'lmasligi mumkin:

export on an NFS server → mount on an NFS client → /srv/shared → files

Shu sabab quyidagi atamalarni sinonim deb hisoblamang:

• disk / saqlash qurilmasi: ma’lumotni saqlaydigan jismoniy yoki virtual qurilma.
• blok qurilma (block device): belgilangan o'lchamdagi bloklar bilan o'qiladigan va yoziladigan qurilmaga kernel taqdim etadigan interfeys.
• bo'lim (partition): bo'limlar jadvali orqali diskdan ajratib olingan oraliq.
• hajm (volume): LVM, RAID, shifrlash yoki boshqa qatlam bo'lim ustida taqdim etadigan mantiqiy blok qurilma.
• fayl tizimi: fayllar, kataloglar, metama’lumotlar va bo'sh joyni tartibga soladigan diskdagi format va uning kerneldagi amalga oshirilishi.
• mount: fayl tizimi daraxtini jarayon ko'radigan katalog daraxtining ma’lum nuqtasiga ulash amali.
• mount nuqtasi (mount point): shu ulanish amalga oshadigan katalog.

Bitta diskda bir nechta bo'lim bo'lishi mumkin. Bitta fayl tizimida millionlab fayl bo'lishi mumkin. Bitta fayl tizimi hatto bir nechta mount nuqtasida ko'rinishi ham mumkin. Btrfs subvolume’lari, bind mount’lar, konteyner overlay’lari va tarmoq saqlash tizimlari "bitta bo'lim — bitta mount" degan sodda tasavvurni buzadi. Shuning uchun ulardan birortasi ishtirok etganda bu tasavvurga tayanmang.

Linux bitta katalog daraxtini ko'rsatadi

Windows’dagi C: va D: kabi alohida disk harflari o'rniga, Linux’dagi oddiy jarayon / dan boshlanadigan yagona daraxtni ko'radi. Boshqa fayl tizimlari /home, /var/lib, /mnt/data yoki administrator tanlagan boshqa joyga ulanadi.

findmnt --target /
findmnt --target /var/log

findmnt -T PATH berilgan yo'l qaysi mount ichida joylashganini topadi. Skriptlar uchun aniq ustunlarni so'rang:

findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS --target /var/log

Namunaviy natija:

/ /dev/nvme0n1p2 ext4 rw,relatime

Bu natija /var/log alohida mount emasligini, u / ga ulangan ext4 fayl tizimi ichida joylashganini bildiradi. Boshqa serverda esa /var/log alohida mantiqiy hajm yoki o'zining tarmoq fayl tizimi bo'lishi mumkin.

Agar mount nuqtasida unga boshqa narsa ulanishidan oldin fayllar bo'lgan bo'lsa, ular o'chmaydi, lekin mount faol bo'lib turgan vaqt davomida yashirinib qoladi. Kutilmaganda bo'sh chiqqan katalogni ko'rib, "ma’lumot yo'qolibdi" degan xulosaga kelish ko'p uchraydigan va oldini olish mumkin bo'lgan xato. Bu mexanizm Mount tushunchalari maqolasida amaliy laboratoriya bilan ko'rib chiqilgan.

VFS: ko'plab fayl tizimlari uchun bitta interfeys

Ilova ext4, XFS yoki NFS ning ichki formatini bilmaydi. U open(), read(), write() va stat() kabi system call’larni chaqiradi, Linux kernelining virtual fayl tizimi (VFS) esa bu umumiy interfeysni maqsad yo'lga haqiqatan egalik qiladigan fayl tizimi amalga oshirilishiga bog'laydi.

process
  │ open("/var/log/app.log")
  ▼
VFS: path lookup, permission checks, mount boundaries
  ▼
ext4 / XFS / NFS / tmpfs / procfs implementation
  ▼
block stack, network stack, or kernel-generated data

Aynan shu abstraksiya tufayli cat, cp va stat diskdagi faylni, tarmoqdagi faylni yoki psevdo fayl tizimidagi obyektni bir xil, yo'lga asoslangan interfeys orqali o'qiy oladi. Lekin har bir fayl tizimi bir xil kafolatlarni bermaydi: katta-kichik harfni farqlash, ruxsatlar modeli, vaqt tamg'alarining aniqligi, hard link’larni qo'llab-quvvatlash, snapshot imkoniyati va yozilgan ma’lumotning saqlanib qolishi (durability) har xil bo'ladi.

ext4 va XFS: nega distributivlarda standart har xil

Ubuntu va Debian sukut bo'yicha root fayl tizimi sifatida ext4 ni o'rnatadi; RHEL oilasidagi ko'pchilik distributivlar (RHEL, Rocky, AlmaLinux) esa XFS ni tanlaydi. Ikkalasi ham jurnalli (journaling) fayl tizimi: metama’lumotdagi o'zgarish asl joyiga yozilishidan oldin, uning qisqa tavsifi avval jurnalga yoziladi. Shunda yozish o'rtasida tizim ishdan chiqsa, keyingi mount paytida bu o'zgarish qayta bajariladi yoki bekor qilinadi va fayl tizimi tuzilmaviy jihatdan nomuvofiq holatda qolmaydi. Ularning farqlari shunchaki qiziqarli fakt emas, administratorning qaroriga ta’sir qiladi:

Amaliy oqibati: agar hajm XFS bilan formatlangan bo'lsa va keyinroq uni kichraytirish kerak bo'lsa (masalan, bitta katta hajmni ikkita kichigiga bo'lish uchun), joyida kichraytirish yo'li yo'q. Yagona yo'l — yangi, kichikroq XFS fayl tizimini yaratib, ma’lumotni unga ko'chirish. Kimgadir kichraytirishni va’da qilishdan oldin fayl tizimi turini tekshiring:

findmnt -no FSTYPE --target /
lsblk -f

Ishlab turgan kernel hozir qaysi fayl tizimi turlarini bilishini ko'rish:

sed -n '1,80p' /proc/filesystems

nodev belgisi bor yozuv odatda bu turni mount qilish uchun blok qurilma kerak emasligini bildiradi. Biror tur bu ro'yxatda bo'lishi uning hozir mount qilinganini anglatmaydi: haqiqiy mount holatini findmnt ko'rsatadi.

Yo'l qanday qilib obyektga aylanadi

/var/log/app.log bir nechta qismdan iborat:

/ → var → log → app.log

Kernel yo'lni qisma-qism aniqlaydi. Katalog yozuvi (dentry) ma’lum katalog ichidagi nomni fayl tizimidagi obyekt bilan bog'laydi; VFS takroriy qidiruvlarni tezlashtirish uchun dentry keshini saqlaydi. Inode — obyektning metama’lumotlar yozuvi: uning turi, ruxsatlari, egasi, hajmi, vaqt tamg'alari va ma’lumot bloklariga ko'rsatkichlar.

Muhim jihat: an’anaviy Unix fayl tizimida fayl nomi uning inode’i ichida saqlanmaydi. Katalog yozuvi nomni inode raqami bilan bog'laydi. Bitta inode’ga bir nechta nom bog'lanishi mumkin, hard link’lar aynan shu mexanizmga asoslanadi. Bu haqda Hard va symbolic link’lar maqolasida gaplashamiz.

Obyekt metama’lumotlarini ko'rish:

stat -c 'name=%n type=%F inode=%i size=%s blocks=%b block-size=%B mount=%m' /etc/hosts

Namunaviy natija:

name=/etc/hosts type=regular file inode=123456 size=302 blocks=8 block-size=512 mount=/

• inode — shu fayl tizimi ichidagi inode raqami.
• size — faylning mantiqiy hajmi.
• blocks × block-size diskda haqiqatan qancha joy ajratilganini ko'rsatadi.
• mount obyekt qaysi mount nuqtasi ostida joylashganini ko'rsatadi.

Inode raqami butun server bo'yicha yagona identifikator emas: ikki obyektni ishonchli farqlash uchun fayl tizimi yoki qurilma identifikatori ham kerak. Overlay, tarmoq va psevdo fayl tizimlari metama’lumotni o'z qoidalariga ko'ra taqdim etadi va bu oddiy lokal diskdagidek bo'lmasligi mumkin.

Blok va mount xaritalarini o'qish

lsblk: blok qatlamlari

lsblk -o NAME,TYPE,SIZE,FSTYPE,FSAVAIL,FSUSE%,MOUNTPOINTS

Namunaviy natija:

NAME        TYPE   SIZE FSTYPE FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1     disk   477G
├─nvme0n1p1 part     1G vfat      900M     10% /boot/efi
└─nvme0n1p2 part   476G ext4      370G     16% /

TYPE=disk — butun qurilma, TYPE=part — bo'lim. Daraxt ota–bola munosabatini ko'rsatadi. LVM bor tizimda lvm turini, dasturiy RAID da raid1 ni ko'rishingiz mumkin. Bo'sh FSTYPE "qurilma ishlatilmayapti" degani emas: u boshqa qatlamning a’zosi, swap maydoni yoki util-linux tanimaydigan format bo'lishi mumkin.

lsblk ning sukut bo'yicha ustunlari util-linux versiyalari orasida o'zgarishi mumkin. Skriptda ustunlarni --output bilan aniq nomlang, natijani tahlil qilish kerak bo'lsa, --json yoki --pairs dan foydalanishni o'ylab ko'ring.

findmnt: joriy mount daraxti

findmnt --real
findmnt --pseudo

--real util-linux haqiqiy deb tasniflagan mount’larni, --pseudo esa proc, sysfs va tmpfs kabi psevdo fayl tizimlarini ajratib ko'rsatadi. Bu ikki filtr har qanday tarmoq, FUSE yoki g'ayrioddiy saqlash sozlamasini siz kutgandek mukammal tasniflaydi deb o'ylamang. Muayyan yo'l uchun findmnt -T ishonchliroq savol.

Mount parametrlarini tekshirish:

findmnt -no SOURCE,FSTYPE,OPTIONS --target /tmp

rw yozish mumkinligini, ro faqat o'qish mumkinligini bildiradi. nosuid, nodev va noexec kabi parametrlar xavfsizlik xatti-harakatiga ta’sir qiladi, lekin ularning bor bo'lishi o'z-o'zidan to'liq himoya kafolati emas.

Sig'imni uch tomondan tekshirish

df: fayl tizimining o'z hisoboti

df -hT /var/log

Namunaviy natija:

Filesystem          Type  Size  Used Avail Use% Mounted on
/dev/nvme0n1p2      ext4  468G   71G  374G  16% /

df muayyan katalog uchun emas, berilgan yo'lga egalik qiladigan fayl tizimi uchun blok sig'imini ko'rsatadi. -h odam o'qiy oladigan, 1024 ning darajalariga asoslangan birliklarni beradi; -T fayl tizimi turini ko'rsatadi. Avail — oddiy jarayon haqiqatan ishlata oladigan joy, u Size - Used ga aynan teng bo'lishi shart emas. Bu farqqa fayl tizimi metama’lumotlari, yaxlitlash, zaxiraga ajratilgan joy va saqlash tizimiga xos hisob-kitoblar sabab bo'ladi.

Inode sig'imi:

df -i /var/log

Filesystem          Inodes   IUsed    IFree IUse% Mounted on
/dev/nvme0n1p2     31195136 1041542 30153594    4% /

Bo'sh baytlar ko'p bo'lsa ham, juda ko'p mayda fayllar inode’larni tugatib qo'yishi va yangi fayl yaratishni to'xtatishi mumkin. "No space left on device" ni ko'rganingizda df -i ni df -h ning o'rniga emas, u bilan birga tekshiring.

du: katalog daraxtini aylanib chiqish

du -xhd1 /var 2>/dev/null | sort -h

• -h: odam o'qiy oladigan birliklar.
• -d1: faqat bir daraja chuqurlikda yig'indi chiqaradi.
• -x: shu fayl tizimi ichida qoladi, boshqa mount qilingan fayl tizimlariga o'tmaydi.
• sort -h: natijani hajm bo'yicha saralaydi.

Ruxsat xatolarini jimgina tashlab yuborish production diagnostikasi uchun yaxshi odat emas. Yuqoridagi 2>/dev/null faqat ixcham namoyish uchun. Haqiqiy tahlilda xatolar oqimini alohida faylda saqlang:

du -xhd1 /var > "$HOME/var-usage.txt" 2> "$HOME/var-usage-errors.txt"
du_status=$?
printf 'du status=%s\n' "$du_status"
wc -l "$HOME/var-usage.txt" "$HOME/var-usage-errors.txt"

du yo'l ostidagi ajratilgan bloklarni sanaydi, df esa fayl tizimining umumiy hisobini beradi. Ikki raqam farq qilishining odatiy sabablari:

• jarayon allaqachon o'chirilgan faylni hali ham ochiq ushlab turibdi;
• ruxsatlar tufayli du daraxtning bir qismini o'qiy olmadi;
• mount yoki bind mount o'lchanayotgan doiraga nima kirishini o'zgartiradi;
• fayl tizimi metama’lumotlari, zaxira bloklar, snapshot’lar yoki copy-on-write qatlamlari du ko'rmaydigan qo'shimcha joy egallaydi;
• siyrak (sparse) faylning ko'rinadigan hajmi unga ajratilgan bloklardan farq qiladi.

df va du ni bitta narsaning raqobatlashuvchi ikki o'lchovi emas, ikki xil savolga javob deb qabul qiling.

df to'la desa-yu, du topa olmasa

Bu jumboqning eng ko'p uchraydigan ko'rinishi — intervyuda ham, production’da ham — katalogdan nomi o'chirilgan, lekin jarayon hali ham ochiq ushlab turgan fayl. rm nomni o'chirdi, shuning uchun nomlar bo'ylab yuradigan du uni endi sanamaydi. Lekin inode va uning ma’lumot bloklari oxirgi ochiq deskriptor yopilgunga qadar bo'shatilmaydi. Fayl tizimining o'z blok hisobini ko'rsatadigan df esa bu joyni hali ham band deb ko'radi. Klassik sabab — ishlab turgan daemon yozishda davom etayotgan log fayli o'chirilgan (yoki noto'g'ri rotatsiya qilingan) bo'ladi va daemon endi nomsiz inode’ga yozaveradi.

Taxmin qilmasdan, holatni tasdiqlang:

sudo lsof -nP +L1

+L1 havolalar soni 1 dan kam bo'lgan ochiq fayllarni ko'rsatadi — aynan o'chirilgan, lekin hali ochiq turgan holat. Namunaviy qator:

COMMAND    PID   USER  FD   TYPE DEVICE   SIZE/OFF NLINK NODE NAME
rsyslogd   812 syslog   7w   REG  259,2 4294967296     0  131 /var/log/app.log (deleted)

NLINK 0 va (deleted) belgisi birga kelishi o'sha 4 GiB faqat 812-PID ning 7-deskriptori tomonidan ushlab turilganini bildiradi. Bu deskriptor yopilishi bilan joy darhol qaytadi.

Xavfsiz yechim — jarayonni deskriptorni o'zining odatiy mexanizmi orqali bo'shatishga majburlash: xizmatni systemctl reload yoki restart qilish, shunda u yangi fayl ochadi. Faqat toza qayta ishga tushirish haqiqatan imkonsiz bo'lsa va siz jarayonni yaxshi tushunsangiz, joyni /proc dagi ochiq deskriptor orqali faylni qisqartirib, joyida bo'shatish mumkin:

sudo truncate -s 0 /proc/812/fd/7

Saqlashni ajratish qatlamlari: LVM, RAID va kvotalar

Hozirgacha bo'lim va fayl tizimi orasidagi bog'lanish o'zgarmas deb hisoblandi. Production’da esa administratordan muntazam ravishda hajmni to'xtatmasdan kattalashtirish, disk ishdan chiqqanda ham ishlab turish yoki bitta foydalanuvchi umumiy fayl tizimini to'ldirib qo'yishining oldini olish so'raladi. Bular uchta alohida muammo bo'lib, saqlash tuzilmasining turli qatlamlarida turgan uchta alohida vosita bilan hal qilinadi.

LVM: bo'limlar va fayl tizimlari orasidagi moslashuvchan qatlam

Logical Volume Manager (LVM) qo'shimcha oraliq qatlam qo'shadi, shunda fayl tizimi endi bitta bo'limning aniq o'lchamiga bog'lanib qolmaydi:

physical volume(s) (PV) → volume group (VG) → logical volume(s) (LV) → file system

• Physical volume — LVM o'z boshqaruviga olgan bo'lim yoki butun disk.
• Volume group bir yoki bir nechta physical volume’ni ajratish mumkin bo'lgan yagona saqlash hovuziga birlashtiradi.
• Logical volume — shu hovuzdan kesib olingan bo'lak. Kernelga u blok qurilma (/dev/<vg-name>/<lv-name>) sifatida ko'rinadi va xuddi bo'limdagi kabi unda fayl tizimi yaratish mumkin.

Foydasi: fayl tizimi online kattalashtirishni qo'llab-quvvatlasa, logical volume’ni keyinroq guruhga yangi physical volume qo'shib, mavjud ma’lumotni ko'chirmasdan kattalashtirish mumkin.

Tuzilmani to'liq vaqtinchalik katalog ichida, ikkita 200 MiB lik loopback fayl ustida quramiz:

mkdir -p ~/lab/lvm && cd ~/lab/lvm
truncate -s 200M disk-a.img disk-b.img
sudo losetup -fP disk-a.img && sudo losetup -fP disk-b.img
losetup -a | grep lab/lvm

losetup -a har bir fayl hozir qaysi /dev/loopN qurilmasiga bog'langanini ko'rsatadi. Aniq raqamlar har bir tizimda har xil bo'ladi, shuning uchun loop0/loop1 deb taxmin qilmasdan, ularni natijadan o'qing.

sudo pvcreate /dev/loop0 /dev/loop1
sudo vgcreate lab_vg /dev/loop0 /dev/loop1
sudo lvcreate -L 300M -n lab_lv lab_vg
sudo mkfs.ext4 /dev/lab_vg/lab_lv

• pvcreate har bir qurilmaga LVM yorlig'ini yozadi, shunda u hovuz a’zosi sifatida taniladi.
• vgcreate lab_vg ... ikkala physical volume’ni bitta 400 MiB lik hovuzga birlashtiradi.
• lvcreate -L 300M -n lab_lv lab_vg shu hovuzdan 300 MiB lik logical volume kesib oladi, qolgan qismi esa keyinroq kattalashtirish uchun ajratilmagan holda qoladi.

Har bir qatlamga ishonishdan oldin uni faqat o'qish orqali tekshiring:

sudo pvs
sudo vgs
sudo lvs

Logical volume’ni online kattalashtirish

LVM ko'pincha aynan shu amal uchun tanlanadi — hech narsani unmount qilmasdan saqlash hajmini kengaytirish:

mkdir -p /mnt/lab-lv
sudo mount /dev/lab_vg/lab_lv /mnt/lab-lv
df -hT /mnt/lab-lv
sudo lvextend -L +50M /dev/lab_vg/lab_lv
sudo resize2fs /dev/lab_vg/lab_lv
df -hT /mnt/lab-lv

lvextend -L +50M volume group’da hali mavjud bo'sh joy hisobidan logical volume’ning o'zini 50 MiB ga kattalashtiradi. Faqat shuning o'zi fayl tizimi o'z hajmini qanday deb bilishini o'zgartirmaydi: fayl tizimini yangi bo'shagan joyga kengaytirish uchun resize2fs (ext4 uchun) yoki xfs_growfs (faqat kattalashadigan, hech qachon kichraymaydigan XFS uchun) alohida buyruq bilan chaqirilishi kerak. Ikkinchi buyruqni unutish — ko'p uchraydigan xato: lvs kattaroq logical volume’ni ko'rsatadi, df esa hali ham eski, kichikroq hajmni ko'rsatadi.

Tozalash, teskari tartibda:

sudo umount /mnt/lab-lv
sudo lvremove lab_vg/lab_lv
sudo vgremove lab_vg
sudo pvremove /dev/loop0 /dev/loop1
sudo losetup -d /dev/loop0
sudo losetup -d /dev/loop1
rm -f ~/lab/lvm/disk-a.img ~/lab/lvm/disk-b.img

RAID: boshqa muammo — moslashuvchanlik emas, zaxiralilik

LVM saqlash hajmini o'zgartirishni osonlashtiradi, lekin o'zi diskning ishdan chiqishidan himoya qilmaydi. Bu RAID (Redundant Array of Independent Disks) ning vazifasi. Linux’da u odatda mdadm bilan boshqariladi va bir nechta jismoniy diskni LVM va fayl tizimlaridan pastroq qatlamda bitta massivga birlashtiradi:

RAID va LVM turli intervyu savollariga javob beradi: RAID apparat nosozligiga chidash va (RAID 0 uchun) xom o'tkazuvchanlik haqida, LVM esa ostidagi disklarga tegmasdan saqlashni o'lchamini o'zgartirish va qayta tashkil qilish haqida. Ular ko'pincha birga ishlatiladi — mdadm massivi LVM boshqaradigan physical volume vazifasini bajaradi — lekin biri ikkinchisining o'rnini bosmaydi va hech biri zaxira nusxaning o'rnini bosmaydi: RAID diskning ishdan chiqishidan himoya qiladi, xato bilan bajarilgan rm yoki ransomware hujumidan emas.

Haqiqiy mdadm massivini qurish va sinash (degraded massiv yaratish, disk nosozligini taqlid qilish, qayta tiklash) alohida laboratoriyaga arziydigan mavzu, shuning uchun bu yerga ataylab kiritilmagan.

Disk kvotalari: bitta foydalanuvchining fayl tizimidagi ulushini cheklash

LVM va RAID qancha saqlash joyi mavjudligini boshqaradi; kvotalar esa bitta fayl tizimining mavjud sig'imi foydalanuvchilar o'rtasida qanday taqsimlanishini boshqaradi. /home kabi umumiy fayl tizimida kvotalar bitta hisob butun joyni egallab, boshqalarni joysiz qoldirishining oldini oladi. Bu ko'p foydalanuvchili serverdagi standart himoya.

Umumiy ish tartibi, tushunchalar darajasida:

1. fayl tizimi kvota hisobi yoqilgan holda mount qilinadi (mount parametrlarida usrquota/grpquota);
2. quotacheck fayl tizimini skanerlab, boshlang'ich foydalanish jadvallarini tuzadi;
3. edquota -u <username> shu foydalanuvchi uchun bloklar va inode’lar bo'yicha soft va hard chegaralarni belgilash uchun muharrirni ochadi;
4. repquota -a kvotasi yoqilgan har bir fayl tizimi uchun joriy foydalanishni sozlangan chegaralar bilan solishtirib ko'rsatadi.

Soft chegaradan vaqtincha oshish mumkin (odatda imtiyozli muddat beriladi); hard chegaradan esa umuman oshib bo'lmaydi va unga yetilgach, keyingi yozishlar xato bilan tugaydi. Kvotalarni boshidan oxirigacha sozlash /etc/fstab mount parametrlariga va fayl tizimiga xos vositalarga bu yerga sig'adigandan chuqurroq kirib boradi. Buni intervyuda tanib olish kerak bo'lgan atamalar va ish tartibi deb qabul qiling va haqiqiy serverda kvotalarni sozlashdan oldin man quotacheck, man edquota va man repquota ni o'qing.

Amaliy vaziyat: xizmat faylga yoza olmayapti

Muammo: ilova /var/lib/myapp ostida yangi fayl yarata olmayapti va uning logida No space left on device chiqyapti. Production’da biror narsani o'chirishdan oldin dalil to'plamoqchisiz.

1. Yo'lni va uning mount’ini aniqlang:

   target=/var/lib/myapp
   test -d "$target" || printf 'directory does not exist: %s\n' "$target" >&2
   findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS --target "$target"
   

2. Blok va inode sig'imini tekshiring:

   df -hT "$target"
   df -i "$target"
   

3. Shu fayl tizimi ichida eng ko'p joy egallaganlarni ko'ring:

   du -xhd1 /var/lib > "$HOME/var-lib-usage.txt" 2> "$HOME/var-lib-usage-errors.txt"
   sort -h "$HOME/var-lib-usage.txt" | tail -n 20
   

4. Mount jimgina faqat o'qish rejimiga o'tib qolmaganini tasdiqlang:

   findmnt -no OPTIONS --target "$target"
   

5. Xulosa chiqarishdan oldin dalillarni ajrating:

   • Use% 100% ga yaqin: ehtimol blok sig'imi muammosi.
   • IUse% 100% ga yaqin: ehtimol mayda fayllar juda ko'p, ya’ni inode muammosi.
   • parametrlarda ro bor: fayl tizimi faqat o'qish rejimiga o'tgan.
   • df katta, du esa kichik: ehtimol o'chirilgan, lekin ochiq turgan fayl yoki fayl tizimiga xos hisob farqi.
   • du xatolar fayli bo'sh emas: tahlil to'liq bo'lmasligi mumkin.

Bu faqat o'qiydigan tekshiruvlarning ba’zilari faqat ruxsatlar tufayli sudo ni talab qilishi mumkin, lekin uni o'ylamasdan qo'shavermang. Ruxsatingiz bo'lsa ham, maxfiy katalog nomlari va hajmlari siz saqlaydigan diagnostika fayliga tushib qolishi mumkinligini unutmang.

Production va distributivlar bo'yicha eslatmalar

• Ubuntu va Debian odatda sukut bo'yicha ext4 ni ishlatadi; RHEL oilasidagi ko'plab o'rnatish profillari esa XFS ni. Taxmin qilmasdan, haqiqiy tizimni findmnt yoki lsblk -f bilan tekshiring.
• Bulutdagi VM’da /dev/nvme... nomi jismoniy NVMe disk borligini kafolatlamaydi: gipervizor shu nom ostida virtual qurilmani taqdim etayotgan bo'lishi mumkin.
• lsblk hostning blok qurilmalarini ko'rsatadi, lekin konteynerning o'z mount ko'rinishi hostda lsblk ko'rsatgandan farq qilishi mumkin.
• Tarmoq fayl tizimida df server ma’lum qilishni tanlagan sig'im va kvota qoidalarini aks ettiradi, bu esa ostidagi jismoniy saqlash bilan aynan mos kelmasligi mumkin.
• /proc, /sys, /run va /dev ning bir qismi oddiy diskdagi kataloglar emas, ularning du natijasini haqiqiy disk sarfi deb talqin qilmang.
• Odatiy diagnostikaga sync yoki df --sync qo'shish disk (I/O) yukini oshiradi. Aniq sababingiz bo'lmasa, standart, faqat o'qiydigan hisob bilan cheklaning.

Keng tarqalgan xatolar

• "Disk", "bo'lim", "fayl tizimi" va "mount nuqtasi" so'zlarini bir xil ma’noda ishlatish.
• lsblk dagi bo'sh FSTYPE ni "bo'sh disk" deb o'qish.
• Yo'l aslida qaysi mount’ga tegishli ekanini tasdiqlamasdan butun disk haqida xulosa chiqarish.
• df -h bo'sh joyni ko'rsatgani uchun inode sig'imi ham yetarli deb o'ylash.
• du va df raqamlari doim aynan mos keladi deb kutish.
• Fayl nomi uning inode’i ichida saqlanadi deb ishonish.
• Psevdo fayl tizimini SSD dagi oddiy katalogdek ko'rish.
• Host va konteyner doim bir xil mount namespace’ni ko'radi deb hisoblash.
• Ruxsat xatolarini yashirib, chala du natijasini to'liq deb qabul qilish.
• Diagnostikani tugatmasdan fayllarni o'chirish yoki fayl tizimini o'zgartirish.

Mashqlar

1. /, /home va /tmp uchun findmnt -T ni bajaring. Ulardan qaysilari bitta fayl tizimini ulashishini aniqlang.
2. lsblk ni o'zingiz tanlagan aniq yettita ustun bilan ishga tushiring va qaysi qatorlar disk, bo'lim yoki boshqa qatlam ekanini belgilang.
3. Uy katalogingizda test fayl yarating va stat yordamida uning inode raqami, mantiqiy hajmi va ajratilgan bloklarini tushuntiring.
4. df -hT "$HOME" va df -i "$HOME" dagi blok va inode ko'rsatkichlarini solishtiring.
5. ~/lab ostida du -hd1 va du --apparent-size -hd1 ni solishtiring. Raqamlar bir xil chiqsa ham, har bir buyruq aslida qaysi o'lchovni so'rayotganini tushuntiring.
6. /proc, /sys va /run ni findmnt bilan tekshiring va har biri uchun ko'rsatilgan manba va fayl tizimi turini qayd eting.

Mashqni bajardim deyish uchun: istalgan yo'l uchun "qaysi mount, qaysi fayl tizimi, qaysi manba va blok hamda inode holati qanday?" degan savolga faqat o'qiydigan buyruqlar yordamida javob bera olishingiz kerak.

Manbalar

• Linux kernel hujjatlari: Virtual File System: https://www.kernel.org/doc/html/latest/filesystems/vfs.html
• Linux man-pages: path_resolution(7): https://man7.org/linux/man-pages/man7/path_resolution.7.html
• Linux man-pages: inode(7): https://man7.org/linux/man-pages/man7/inode.7.html
• util-linux: lsblk(8): https://man7.org/linux/man-pages/man8/lsblk.8.html
• util-linux: findmnt(8): https://man7.org/linux/man-pages/man8/findmnt.8.html
• GNU Coreutils qo'llanmasi: df invocation: https://www.gnu.org/software/coreutils/manual/html_node/df-invocation.html
• GNU Coreutils qo'llanmasi: du invocation: https://www.gnu.org/software/coreutils/manual/html_node/du-invocation.html
• GNU Coreutils qo'llanmasi: stat invocation: https://www.gnu.org/software/coreutils/manual/html_node/stat-invocation.html
• Linux man-pages: mount namespaces: https://man7.org/linux/man-pages/man7/mount_namespaces.7.html
• Red Hat: LVM Logical Volumes: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/index
• Linux man-pages: lvm(8): https://man7.org/linux/man-pages/man8/lvm.8.html
• Linux man-pages: mdadm(8): https://man7.org/linux/man-pages/man8/mdadm.8.html
• Linux man-pages: quotacheck(8), edquota(8), repquota(8): https://man7.org/linux/man-pages/man8/quotacheck.8.html
• XFS hujjatlari: xfs_growfs(8): https://man7.org/linux/man-pages/man8/xfs_growfs.8.html