Tarkibga o'tish

Mount tushunchalari

Diskda fayl tizimi borligi uning fayllari / daraxtida avtomatik ko'rinadi degani emas. Linux fayl tizimini ma’lum katalogga ulaydi va shundan keyingina jarayonlar unga o'sha katalog yo'li orqali murojaat qila oladi. Bu ulash amali mount, u amalga oshadigan katalog esa mount nuqtasi (mount point) deyiladi.

Mount fayllarni ko'chirmaydi ham, nusxalamaydi ham. U Disk va fayl tizimi asoslari maqolasida tanishtirilgan VFS daraxtiga yangi ko'rinishni ulaydi. Shu moduldagi Yo'llar va fayl turlari maqolasi yo'lni aniqlash mount chegarasiga yetganda qanday davom etishini amalda ko'rsatadi. Quyida mount’ni tashkil qiladigan manba, fayl tizimi turi, mount nuqtasi va parametrlarni; findmnt, mountpoint, lsblk va /proc/self/mountinfo ni qanday o'qishni; mavjud katalogga boshqa narsa mount qilinganda uning ichidagi mazmun nega vaqtincha yo'qolishini; kernelning joriy holati va /etc/fstab dagi doimiy reja o'rtasidagi farqni; nega qurilma nomidan ko'ra UUID= afzal ekanini; asosiy mount parametrlari va ularning chegaralarini ko'rib chiqamiz. Oxirida bir martalik VM’da "disk ulangan, lekin ilova boshqa joyga yozyapti" muammosini tekshirayotib, tmpfs ni xavfsiz mount va unmount qilamiz.

Mount’ning to'rt qismi

Oddiy mount quyidagi tushunchalarni bir-biriga bog'laydi:

source + file system type + options ──> mount point
  • manba (source): blok qurilma, UUID=..., tarmoq orqali ulashilgan resurs (export), tmpfs kabi manba yoki bind mount uchun mavjud katalog.
  • fayl tizimi turi: ext4, xfs, tmpfs yoki nfs kabi kernel drayveri.
  • mount nuqtasi: mavjud katalog, ba’zi hollarda esa fayl.
  • parametrlar (options): ro, rw, nosuid, nodev, noexec va fayl tizimiga xos sozlamalar.

Masalan:

sudo mount -t ext4 -o ro UUID=<file-system-uuid> /mnt/data

Bu buyruq kerneldan shu UUID bilan aniqlanadigan ext4 fayl tizimini /mnt/data ga faqat o'qish rejimida mount qilishni so'raydi. sudo kerak, chunki tizimning mount jadvalini o'zgartirish odatda CAP_SYS_ADMIN imkoniyatini (capability) talab qiladi.

Danger

Yuqoridagi buyruqni production serverda haqiqiy UUID bilan tajriba sifatida ishga tushirmang. Noto'g'ri qurilmani yoki band mount nuqtasiga mount qilish ma’lumotni yashirib qo'yishi, ilovani noto'g'ri fayl tizimiga yo'naltirishi va yozilayotgan ma’lumotlarni buzishi mumkin. Avval lsblk -f, findmnt va zaxira nusxa holatini faqat o'qish orqali tekshiring. Holatni o'zgartiradigan har qanday mount snapshot olingan laboratoriya VM’ida bajariladi.

Bitta daraxt, ko'p fayl tizimi

Foydalanuvchi /, /boot, /var/lib/data va /proc ni yagona katalog daraxti sifatida ko'radi. Bu daraxt ortida turli manbalar ishlayotgan bo'lishi mumkin:

/                     the root file system
├── boot              possibly its own disk partition
├── proc              the proc file system the kernel provides
└── var/lib/data      possibly a separate ext4/XFS file system, or a network file system

VFS bu turli amalga oshirishlarni bir xil umumiy open, read, write va stat amallari orqali taqdim etadi. Shuning uchun ilova shunchaki /var/lib/data/orders.db yo'lini ochadi; u NVMe bo'limidami, LVM hajmidami yoki tarmoq fayl tizimidami — buni ilova emas, mount jadvali hal qiladi.

Mount ostida yashirinib qolgan eski mazmun

Faraz qilaylik, /mnt/data da allaqachon old.txt nomli fayl bor. Agar shu katalogning ustiga boshqa fayl tizimi mount qilinsa, old.txt o'chmaydi, lekin mount olib tashlanmaguncha bu yo'l orqali unga yetib bo'lmaydi.

before the mount: /mnt/data/old.txt
after the mount:  /mnt/data/<content of the mounted file system>

Mount olib tashlangach, katalogning oldingi mazmuni yana ko'rinadi. Bo'sh bo'lmagan mount nuqtasi production uchun xavf: agar mount ko'tarilmay qolsa, ilova root fayl tizimidagi yashirin katalogga yozib qo'yishi mumkin, mount qaytgach esa ma’lumot "yo'qolib qolgandek" ko'rinadi.

Mount qilishdan oldin mount nuqtasi bo'shligini tekshirish:

find <mount-point> -mindepth 1 -maxdepth 1 -print

<mount-point> ni haqiqiy katalog bilan almashtiring. Hech narsa chiqmasa, katalog bo'sh. Ruxsat xatosini "bo'sh" deb tushunmang.

Joriy mount holatini o'qish

Joriy mount holati bo'yicha asosiy manba — kernel. Zamonaviy Linux tizimida findmnt odatda /proc/self/mountinfo ni o'qiydi va uni qulay ko'rinishda taqdim etadi.

Berilgan yo'l qaysi fayl tizimiga tegishli?

findmnt -T /var/log

Namunaviy natija:

TARGET SOURCE         FSTYPE OPTIONS
/      /dev/mapper/ubuntu--vg-ubuntu--lv
                       ext4   rw,relatime

Bu misolda /var/log uchun eng yaqin mount — /, uning manbasi LVM qurilmasi, turi ext4 va unga yozish mumkin (rw). Terminal kengligiga qarab qatorlar bo'linib chiqishi mumkin.

Skriptlar uchun ustunlarni aniq nomlang:

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

findmnt ning sukut bo'yicha ustunlari versiyalar orasida o'zgarishi mumkin, shuning uchun avtomatlashtirishda ustunlarni -o bilan nomlash muhim.

Yo'l aynan mount nuqtasimi?

mountpoint /var/log
printf 'exit=%s\n' "$?"

0 — yo'l aynan mount nuqtasi; 1 — mount nuqtasi emas. Bu /var/log hech qaysi fayl tizimiga tegishli emas degani emas: u shunchaki o'zi alohida ulanish chegarasi emasligini bildiradi.

Skriptlar uchun ovozsiz tekshiruv:

if mountpoint -q /var/log; then
    printf '/var/log is a separate mount point\n'
else
    printf '/var/log is not a separate mount point\n'
fi

Qurilmalar va mount’lar o'rtasidagi bog'liqlik

lsblk -o NAME,TYPE,FSTYPE,UUID,SIZE,MOUNTPOINTS

lsblk blok qurilmalar daraxtini ko'rsatadi. U tmpfs, NFS yoki bind mount kabi blok qurilmaga to'g'ridan-to'g'ri bog'lanmagan mount’larni to'liq tavsiflamaydi. Mount’larning to'liq manzarasi uchun findmnt dan, disk topologiyasi uchun esa lsblk dan foydalaning.

/proc/self/mountinfo

head -n 3 /proc/self/mountinfo

Bitta qatorning soddalashtirilgan tuzilishi:

mount-id parent-id major:minor root mount-point mount-options ... - fstype source super-options

- ajratuvchisidan oldin mount daraxti va aynan shu ulanish haqidagi ma’lumot, undan keyin esa fayl tizimi turi, manba va superblok parametrlari keladi. Yo'llardagi bo'sh joy kabi belgilar sakkizlik (octal) escape ko'rinishida chiqishi mumkin. Buni qo'lda tahlil qilish kamdan-kam kerak bo'ladi — odatda findmnt yaxshiroq vosita.

Manba turlari

Blok qurilmalar va barqaror identifikatorlar

/dev/sdb1 interaktiv diagnostikada qulay, lekin apparatni aniqlash tartibi o'zgarsa, qurilma nomi ham o'zgarishi mumkin. Doimiy konfiguratsiyada buning o'rniga fayl tizimining UUID yoki yorlig'i (label) ishlatilishi kerak:

lsblk -f
blkid

fstab dagi namunaviy manba:

UUID=2b0d0a12-1111-4222-8333-abcdef123456

UUID ni taxmin qilmang. Uni lsblk -f bilan yoki root huquqi kerak bo'lsa, sudo blkid bilan aniq tekshiring. Klonlangan disk asl diskniki bilan bir xil UUID ni saqlab qolishi mumkin — tizimda uning yagonaligini ham tekshiring.

Psevdo fayl tizimlari

proc, sysfs va tmpfs hech qanday disk bo'limiga mos kelmasligi mumkin:

findmnt -t proc,sysfs,tmpfs
  • proc jarayonlar va kernel haqidagi ma’lumotni /proc orqali ko'rsatadi.
  • sysfs qurilmalar va kernel obyektlarini /sys orqali ko'rsatadi.
  • tmpfs ma’lumotni xotira va swap’da saqlaydi; uning mazmuni qayta yuklanish yoki unmount’dan keyin saqlanmaydi.

tmpfs ni "faqat RAM" deb tavsiflash juda soddalashtirish: uning sahifalari swap’ga chiqarilishi mumkin, hajm chegarasi esa mount parametri orqali boshqariladi.

Tarmoq fayl tizimlari

NFS manbasi server:/export ko'rinishida bo'ladi; boshqa tarmoq fayl tizimlari o'z sintaksisidan foydalanadi. Bunday mount faqat lokal diskka emas, DNS, tarmoq, autentifikatsiya va masofaviy server holatiga ham bog'liq. _netdev, nofail yoki systemd automount unit’i kabi yuklanish vaqtidagi siyosatlar vaziyatga qarab tanlanadi — ularning hech biri hamma uchun standart emas.

Bind mount’lar

Bind mount mavjud katalog daraxtini boshqa yo'lda yana ko'rinadigan qiladi:

sudo mount --bind <source-directory> <mount-point>

Bu na nusxa, na symbolic link. Bind mount VFS mount jadvaliga yangi yozuv qo'shadi; u ko'pincha konteynerlar va chroot muhitlarida tanlangan kataloglarni ko'rsatish uchun ishlatiladi. Symbolic link’dan farqli ravishda, natijaga jarayonning mount namespace’i va mount parametrlari ta’sir qiladi.

Warning

Production’da bind mount’ni sinab ko'rishdan oldin manbani ham, maqsadni ham realpath -e, findmnt -T va find bilan tekshiring. realpath -e kanonik yo'lni faqat har bir qism haqiqatan mavjud bo'lsagina chiqaradi; xato yoki bo'sh natija taxminiy maqsadga ishonmaslik kerakligini bildiradi. Bu vosita shu modulning keyingi qismidagi Yo'llar va fayl turlari maqolasida chuqurroq yoritilgan. Noto'g'ri maqsad mavjud ma’lumotni vaqtincha yashirib qo'yadi. Rollback — katalog mazmunini o'chirish emas, shunchaki yangi bind mount’ni umount <mount-point> bilan olib tashlash.

Mount parametrlari va ularning chegaralari

Ko'p uchraydigan parametrlar:

Parametr Vazifasi Muhim cheklov
ro faqat o'qish rejimi fayl tizimining o'zi va ostidagi qatlamlarning xatti-harakati baribir ahamiyatli
rw o'qish va yozish ruxsatlar baribir foydalanuvchi nima qila olishini cheklaydi
nosuid set-user-ID va set-group-ID bitlarini e’tiborsiz qoldiradi imtiyozni oshirishning barcha yo'llarini yopmaydi
nodev bu yerdagi qurilma maxsus fayllarini talqin qilmaydi fayl tizimidagi boshqa xavflarni yo'q qilmaydi
noexec shu mount’dan to'g'ridan-to'g'ri bajarishni bloklaydi faylni interpretator orqali o'qib bajarishning oldini to'liq olmaydi
relatime atime qanchalik tez-tez yangilanishini kamaytiradi aniq xatti-harakati kernel va parametrga bog'liq
noatime murojaat vaqti (atime) yangilanishini butunlay o'chiradi atime’ga tayanadigan dasturlarga ta’sir qilishi mumkin

noexec, nodev va nosuid chuqurlashgan himoya (defense in depth) uchun foydali choralar, lekin ular katalog ruxsatlari, majburiy kirish nazorati (MAC) siyosati, konteyner izolyatsiyasi yoki ilova darajasidagi xavfsizlikning o'rnini bosmaydi.

Amalda qo'llanayotgan parametrlarni tekshirish:

findmnt -no TARGET,VFS-OPTIONS,FS-OPTIONS -T <path>

util-linux’ning yangi versiyalari VFS darajasidagi parametrlarni fayl tizimiga xos parametrlardan ajrata oladi. Eski versiyada ustun nomlari boshqacha bo'lsa, findmnt --help dagi Available output columns ro'yxatini tekshiring.

Joriy holat va /etc/fstab

mount ni bajarish kernelning joriy holatini o'zgartiradi. Bu ulanish qayta yuklangandan keyin ham qayta yaratilishi uchun odatda doimiy konfiguratsiya kerak bo'ladi — ko'pincha /etc/fstab yoki systemd mount unit’i.

/etc/fstab da oltita maydon bor:

source  mount-point  fstype  options  dump  fsck-pass

Misol:

UUID=<verified-uuid>  /srv/data  ext4  defaults,nosuid,nodev  0  2
  1. source: UUID, yorliq (label), qurilma yoki tarmoq manbasi.
  2. mount-point: ulanadigan katalog.
  3. fstype: fayl tizimi turi.
  4. options: vergul bilan ajratilgan sozlamalar.
  5. dump: eski zaxira nusxa vositasi uchun maydon, odatda 0.
  6. fsck-pass: yuklanishdagi tekshirish tartibi; root fayl tizimi odatda 1, tekshiriladigan boshqa lokal fayl tizimlari 2, tekshirilmaydiganlari 0.

fsck siyosati distributiv va fayl tizimiga qarab farq qiladi. ext oilasi misolidagi pass qiymatini XFS ga ko'r-ko'rona ko'chirmang.

Haqiqiy fstab ni o'zgartirmasdan tekshirish

Joriy rejani faqat o'qish orqali ko'rish:

findmnt --fstab --evaluate

Mashq uchun alohida fayl yarating:

lab=$(mktemp -d)
printf 'tmpfs %s tmpfs size=8M,nosuid,nodev,noexec 0 0\n' "$lab/mnt" > "$lab/fstab.test"
mkdir "$lab/mnt"
findmnt --verify --tab-file "$lab/fstab.test"

Bu hech narsani mount qilmasdan test jadvalini tekshiradi. Kutiladigan natija Success, no errors or warnings detected ga yaqin bo'ladi; aniq matn util-linux versiyasiga bog'liq.

Tozalash:

printf 'directory to remove: %q\n' "$lab"
find "$lab" -maxdepth 2 -ls
rm -rI -- "$lab"

Danger

/etc/fstab dagi xato yuklanish jarayonini emergency mode’da to'xtatib qo'yishi yoki xizmatni noto'g'ri diskka yozishga majbur qilishi mumkin. Production’da avval faylning vaqt tamg'ali zaxira nusxasini oling, manba va maqsadni faqat o'qish orqali tekshiring va nusxani findmnt --verify --tab-file <copy> bilan tekshiring. Haqiqiy o'zgarishdan keyin tasdiqlangan texnik xizmat oynasi (maintenance window) va konsolga kirish imkonisiz serverni qayta yuklamang. Bu maqoladagi laboratoriya haqiqiy /etc/fstab ga tegmaydi.

fsck: kernel fayl tizimini qachon tekshiradi

Yuqorida ko'rsatilgan /etc/fstab ning oltinchi maydoni — fsck-pass — yuklanish paytida shu mount uchun fsck (yoki u chaqiradigan fayl tizimiga xos tekshiruvchi, masalan ext4 uchun e2fsck) avtomatik ishga tushishini va qaysi tartibda ishlashini boshqaradi:

  • 0: bu fayl tizimini yuklanishda hech qachon tekshirmaslik.
  • 1: birinchi bo'lib tekshirish — root fayl tizimi uchun ajratilgan.
  • 2: root fayl tizimidan keyin tekshirish; fayl tizimlari turli disklarda bo'lsa, parallel ravishda.

Yuklanishdagi pass raqamidan tashqari, ext oilasidagi fayl tizimlari ikkita mustaqil hisoblagich asosida avtomatik tekshiruvni ishga tushirishi mumkin. Ikkalasi ham tune2fs bilan sozlanadi:

sudo tune2fs -l /dev/nvme0n1p2 | grep -E 'Mount count|Maximum mount count|Last checked|Check interval'
  • tune2fs -c <max-mounts> fayl tizimi necha marta mount qilingandan keyin kernel keyingi yuklanishda tekshiruvni majburlashini belgilaydi.
  • tune2fs -i <interval> (masalan, olti oy uchun 6m) mount soniga qaramasdan, tekshiruvlar orasidagi eng uzoq vaqtni belgilaydi.

Oylab uzluksiz ishlaydigan zamonaviy ext4 serverida bu hisoblagichlarning hech biri odatda ishga tushmaydi, chunki bulut va server image’larida ikkalasi ham ko'pincha -1/0 (o'chirilgan) qilib qo'yiladi — aynan rejalashtirilmagan uzoq tekshiruv yuklanishni kechiktirmasligi uchun. XFS bu mount soni/interval mexanizmidan umuman foydalanmaydi; uning yaxlitlikni tekshirish modeli avtomatik davriy fsck ga emas, aniq ishga tushiriladigan xfs_repair ga tayanadi.

Yana bir sabab — toza bo'lmagan unmount: tizimning ishdan chiqishi, elektr uzilishi yoki majburiy o'chirish fayl tizimiga toza unmount qilinganini qayd etishga imkon bermaydi. Keyingi mount urinishida kernel yoki mount yordamchisi "iflos" (dirty) belgisini aniqlaydi va fayl tizimiga yana ishonishdan oldin tekshiruv ishga tushadi (yoki talab qilinadi).

fsck ni qo'lda ishga tushirish

sudo fsck -n /dev/nvme0n1p2
  • -n: tuzatish bo'yicha har bir so'rovga "yo'q" deb javob beradi va faqat topganini xabar qiladi — fayl tizimida muammo bor-yo'qligini hech narsani o'zgartirmasdan ko'rishning xavfsiz, faqat o'qiydigan usuli.
  • -f: fayl tizimi toza deb belgilangan bo'lsa ham to'liq tekshiruvni majburlaydi. Bu toza belgisi aks ettirmaydigan buzilishdan shubha qilganingizda kerak.
  • -y: har bir so'rovga avtomatik "ha" deb javob beradi va so'ramasdan tuzatishlarni qo'llaydi. Nazoratsiz tiklash skriptlari uchun mos, lekin faqat -n nima o'zgarishini allaqachon ko'rsatgandan keyin.

Danger

fsck ni (-y bilan yoki usiz) hech qachon mount qilingan, yozish mumkin bo'lgan fayl tizimiga qarshi ishga tushirmang. Tekshiruvchi diskdagi tuzilmalarga faqat o'zi murojaat qiladi deb hisoblaydi; ostida o'zgartirilayotgan jonli fayl tizimi nomuvofiq natijalarga yoki qo'shimcha buzilishga olib kelishi mumkin. Shu sababli Linux’da fsck himoya chorasi sifatida odatda mount qilingan, o'qish-yozish rejimidagi fayl tizimida ishlashdan bosh tortadi. Amalda keng tarqalgan yagona istisno — root fayl tizimi: u odatda foydalanuvchi muhiti va ko'p yozishlar boshlanishidan oldin, initramfs/systemd’ning erta yuklanish bosqichida tekshiriladi. Bu ishlab turgan desktop yoki server sessiyasi ostidagi to'liq jonli root’ni fsck qilish emas. Boshqa har qanday fayl tizimi uchun -y bilan tuzatish bosqichini ishga tushirishdan oldin uni unmount qiling, root fayl tizimi uchun esa single-user/rescue rejimiga qayta yuklang.

Shubhali yuklanishdan keyin avtomatik tekshiruv ishga tushganmi va u nima topganini bilish uchun birinchi navbatda dmesg yoki journalctl -b ni o'qing:

journalctl -b | grep -i 'fsck\|clean\|forced'

Disk va fayl tizimi asoslari maqolasida ko'rilganidek, LVM bilan yangi hajm ajratish va keyinroq uni qachon yaxlitlikka tekshirish kerakligini hal qilish — bir-biriga bog'liq, lekin alohida masalalar. LVM fayl tizimi ostidagi blok qurilmani boshqaradi, fsck esa fayl tizimi uning ustida allaqachon mavjud bo'lgandan keyin uning o'z metama’lumotlarini tekshiradi.

Mount namespace’lar: har bir jarayon bir xil daraxtni ko'rmaydi

Mount namespace jarayonlar guruhiga mount ro'yxatining o'zining alohida ko'rinishini beradi. Konteyner ichidagi jarayon host bilan bir xil yo'l nomlaridan foydalanishi, lekin aslida butunlay boshqa mount daraxtini ko'rishi mumkin.

Joriy shell’ning o'z ko'rinishi:

readlink /proc/self/ns/mnt
findmnt -N "$$"

Boshqa jarayonning mount ma’lumotlari:

sudo head -n 3 /proc/<PID>/mountinfo

<PID> ni tekshirilayotgan jarayon ID si bilan almashtiring. sudo faqat procfs ruxsatlari uni o'qishni cheklagan holda kerak bo'ladi.

Mount propagation bitta namespace’da yoki bind mount qilingan daraxtda keyinchalik yuz beradigan mount yoki unmount hodisasi boshqasiga tarqaladimi-yo'qmi, shuni belgilaydi. shared, slave, private va unbindable holatlari konteyner runtime’lari uchun muhim, lekin production’da mount --make-* bilan tajriba qilmang. Noto'g'ri propagation host va konteyner ko'rinishlariga kutilmagan ta’sir ko'rsatishi mumkin.

Laboratoriya: tmpfs ni mount qilish

Bu laboratoriya mount jadvalini o'zgartiradi. Uni faqat snapshot olingandan keyin, bir martalik Ubuntu Server LTS VM’ida bajaring. Agar siz ishlayotgan konteynerga CAP_SYS_ADMIN berilmagan bo'lsa, buyruq xato beradi — bu imkoniyatni qo'shish o'rniga VM’dan foydalaning.

Maqsad va boshlang'ich holat

Hajmi 16 MiB bilan cheklangan, oddiy foydalanuvchi yoza oladigan va nosuid,nodev,noexec bilan mount qilingan vaqtinchalik tmpfs yaratiladi. Qayta yuklanish yoki unmount uning mazmunini yo'q qiladi.

lab_mount=/mnt/fs-course-tmpfs
findmnt --mountpoint "$lab_mount"
test -e "$lab_mount" && find "$lab_mount" -mindepth 1 -maxdepth 1 -ls

Bu yerda findmnt hech narsa topmasligi kerak. Agar katalog allaqachon mavjud va bo'sh bo'lmasa, davom etmang.

Mount nuqtasini tayyorlash

sudo mkdir -p "$lab_mount"
sudo find "$lab_mount" -mindepth 1 -maxdepth 1 -ls

/mnt ostida katalog yaratish uchun sudo kerak. Ikkinchi buyruq hech narsa chiqarmasa, katalog bo'sh.

tmpfs ni mount qilish

Shell sudo ishga tushishidan oldin $(id -u) va $(id -g) ni joriy foydalanuvchi qiymatlariga almashtiradi:

sudo mount -t tmpfs \
  -o size=16M,nosuid,nodev,noexec,mode=0700,uid="$(id -u)",gid="$(id -g)" \
  tmpfs "$lab_mount"

Darhol tekshiring:

mountpoint "$lab_mount"
findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS --mountpoint "$lab_mount"
df -hT "$lab_mount"

Natijada turi tmpfs, hajmi taxminan 16M va parametrlar orasida nosuid, nodev, noexec bo'lishi kerak. Kernel qo'shimcha parametrlarni ham ko'rsatishi mumkin.

Yozish va sig'imni tekshirish

printf 'mount lab\n' > "$lab_mount/marker.txt"
stat "$lab_mount/marker.txt"
df -h "$lab_mount"

Fayl joriy foydalanuvchiga tegishli bo'lishi kerak. Bu qadam noexec ni "aylanib o'tish"ga urinmaydi — u faqat parametr mavjudligini findmnt orqali tasdiqlaydi.

Unmount va rollback

Avval shell’ning o'zi mount ichida turmaganini tasdiqlang:

cd /
sudo fuser -vm "$lab_mount"

fuser mount’dan qaysi jarayonlar foydalanayotganini ko'rsatishi mumkin; natijani o'qimasdan turib jarayonlarni majburan o'ldirmang. So'ng:

sudo umount "$lab_mount"
mountpoint "$lab_mount"
sudo rmdir "$lab_mount"

Unmount’dan keyin mountpoint 1 chiqish holatini qaytarishi kutiladi. marker.txt saqlanmaydi. Agar umount: target is busy chiqsa:

  1. pwd -P bilan shell’ning o'zi mount ichida emasligini tasdiqlang;
  2. sudo fuser -vm "$lab_mount" bilan aybdor jarayonlarni toping;
  3. tegishli xizmat yoki jarayonni odatdagi usulda to'xtating;
  4. umount ni qayta bajaring.

umount -l (lazy unmount) asl muammoni yashirib, resursni keyinroq ajratishi mumkin; sababini tushunmasdan uni production’da ishlatmang. Bu laboratoriyadan oldin olingan VM snapshot to'liq rollback nuqtangiz.

Amaliy vaziyat: ilova noto'g'ri diskka yozyapti

Ilova ma’lumotlari /srv/data da bo'lishi va bu yo'l alohida diskka mount qilingan bo'lishi kerak. Root fayl tizimi esa to'lib boryapti.

1. Yo'lning haqiqiy mount’ini toping

findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS -T /srv/data
mountpoint /srv/data
df -hT /srv/data

Agar findmnt -T TARGET=/ ni ko'rsatsa va mountpoint 1 chiqish holatini qaytarsa, demak /srv/data umuman alohida mount emas — ilova root fayl tizimidagi oddiy katalogga yozib kelgan.

2. Kutilgan konfiguratsiyani tekshiring

findmnt --fstab --target /srv/data
lsblk -f

Natijani talqin qilish:

  • mos fstab yozuvi yo'q: doimiy mount umuman sozlanmagan bo'lishi mumkin.
  • yozuv bor, lekin kernel bunday mount’ni ko'rsatmayapti: mount urinishi ehtimol muvaffaqiyatsiz bo'lgan.
  • UUID lsblk -f da topilmayapti: qurilma ulanmagan, UUID noto'g'ri yoki siz boshqa namespace’ga qarayapsiz.

3. Muvaffaqiyatsizlik manbasini toping

systemd bilan ishlaydigan Ubuntu va RHEL oilasi tizimlarida:

systemctl --failed
journalctl -b -p warning..alert

Mount unit’ining nomini taxmin qilish o'rniga:

systemd-escape --path --suffix=mount /srv/data

Natija odatda srv-data.mount bo'ladi. So'ng aynan shu unit’ni tekshiring:

systemctl status srv-data.mount
journalctl -b -u srv-data.mount

4. Biror narsani o'zgartirishdan oldingi xulosa

Ilovani avval to'xtatmasdan to'g'ri diskni mount qilish mavjud /srv/data mazmunini yashirib qo'yishi va yozishlarni ikki joyga bo'lib yuborishi mumkin. To'g'ri tiklash rejasi odatda quyidagicha bo'ladi:

  1. texnik xizmat oynasini rejalashtiring;
  2. ilovani nazorat ostida to'xtating;
  3. hozir root fayl tizimida turgan mavjud ma’lumotlarning zaxira nusxasini oling;
  4. kerakli disk va fayl tizimini faqat o'qish orqali tekshiring;
  5. uni endi bo'sh bo'lgan mount nuqtasiga mount qiling;
  6. ma’lumotlarni tekshirilgan jarayon orqali ko'chiring yoki tiklang;
  7. egalik, ruxsatlar va xizmat holatini tekshiring;
  8. rollback uchun eski nusxani saqlab qo'ying.

Bu qadamlar aynan shu production muhitiga moslashtirilgan runbook’ni talab qiladi; shunchaki mount -a ni bajarish o'z-o'zidan xavfsiz yechim emas.

Keng tarqalgan xatolar

mount natijasini disklar ro'yxati deb hisoblash

Mount jadvaliga psevdo, tarmoq va bind mount’lar ham kiradi. lsblk blok qurilmalarni, findmnt esa VFS ulanishlarini ko'rsatadi.

df va du farqini unutish

df fayl tizimining ajratilgan bloklarini hisoblaydi; du ko'rinadigan katalog daraxtidagi fayllarni qo'shib chiqadi. O'chirilgan, lekin ochiq turgan fayl yoki mount ostida yashirinib qolgan katalog ikki raqam farq qilishiga sabab bo'lishi mumkin.

Mount nuqtasi bo'shligini tekshirmaslik

Mount mavjud mazmunni o'chirmaydi — uni vaqtincha yashiradi. Kerakli mount faol bo'lmagan paytda ilova root fayl tizimiga yozib qo'ygan bo'lishi mumkin.

/dev/sdb1 ni doimiy nom deb hisoblash

Qurilmalarni aniqlash tartibi o'zgarishi mumkin. fstab da tekshirilgan UUID= yoki o'rinli bo'lsa LABEL= dan foydalaning.

noexec ni to'liq xavfsizlik chegarasi deb hisoblash

U to'g'ridan-to'g'ri bajarishni bloklaydi, lekin faylni o'qib, talqin qilishning barcha yo'llarini emas. Ruxsatlar va himoyaning boshqa qatlamlari baribir kerak.

Konteyner va uning hosti bir xil mount’larni ko'radi deb o'ylash

Mount namespace tufayli /srv/data kabi bir xil yo'l satri turli jarayonlar uchun turli manbaga olib borishi mumkin. Bu muhim bo'lganda /proc/<PID>/mountinfo ni tekshiring.

Mashqlar

  1. /, /proc, /sys, /run va uy katalogingiz uchun findmnt -T ni bajaring. Har birining manbasi, turi va eng yaqin mount nuqtasini qayd eting.
  2. lsblk -f va findmnt natijalarini solishtiring. Ulardan faqat bittasida ko'rinadigan kamida ikkita mount’ni toping va sababini tushuntiring.
  3. /proc/self/mountinfo da root mount qatorini toping. Uning mount-id, parent-id, mount nuqtasi, tur va manba maydonlarini aniqlang.
  4. Vaqtinchalik fstab.test yarating, unga noto'g'ri parametr qo'shing va xatoni findmnt --verify --tab-file bilan toping. Haqiqiy /etc/fstab ga tegmang.
  5. Bir martalik, snapshot olingan VM’da tmpfs laboratoriyasini bajaring. mountpoint ning chiqish holatini mount’dan oldin, mount paytida va undan keyin qayd eting.
  6. Bitta konteyner ishlayotgan test hostda host shell’i va konteyner PID i uchun /proc/<PID>/mountinfo ni solishtiring. Hech qanday propagation sozlamasini o'zgartirmang.

Mashqni bajardim deyish uchun: istalgan yo'l uchun "qaysi manba, qaysi fayl tizimi turi, qaysi mount nuqtasi va qaysi namespace?" degan savolga haqiqiy buyruq natijalariga tayangan holda javob bera olishingiz kerak.

Manbalar

  • util-linux: mount(8): https://man7.org/linux/man-pages/man8/mount.8.html
  • util-linux: findmnt(8): https://man7.org/linux/man-pages/man8/findmnt.8.html
  • util-linux: mountpoint(1): https://man7.org/linux/man-pages/man1/mountpoint.1.html
  • Linux man-pages: fstab(5): https://man7.org/linux/man-pages/man5/fstab.5.html
  • Linux man-pages: mount namespaces: https://man7.org/linux/man-pages/man7/mount_namespaces.7.html
  • Linux kernel hujjatlari: Shared Subtrees: https://docs.kernel.org/filesystems/sharedsubtree.html
  • Linux kernel hujjatlari: Virtual File System: https://docs.kernel.org/filesystems/vfs.html
  • Linux man-pages: fsck(8): https://man7.org/linux/man-pages/man8/fsck.8.html
  • Linux man-pages: e2fsck(8): https://man7.org/linux/man-pages/man8/e2fsck.8.html
  • Linux man-pages: tune2fs(8): https://man7.org/linux/man-pages/man8/tune2fs.8.html