Periyodik olarak Merkezi Dağıtım Merkezine geçmek için, DevOps pozisyonu için başta St. Petersburg ve Moskova olmak üzere çeşitli büyük şirketlerle görüşmeler yapıyorum. Pek çok şirketin (birçok iyi şirketin, örneğin Yandex'in) iki benzer soruyu sorduğunu fark ettim:
- inode nedir;
- hangi nedenlerden dolayı disk yazma hatası alabilirsiniz (veya örneğin: neden disk alanınız tükenebilir, özü aynıdır).
Çoğu zaman olduğu gibi bu konuyu iyi bildiğimden emindim ama açıklamaya başlar başlamaz bilgideki boşluklar ortaya çıktı. Bilgilerimi sistemleştirmek, boşlukları doldurmak ve artık kendimi utandırmamak için bu yazıyı yazıyorum, belki bir başkasının işine yarar.
En alttan başlayacağım, yani. bir sabit sürücüden (flaş sürücüleri, SSD'leri ve diğer modern şeyleri atacağız; örneğin, blok boyutu 20 bayt olduğundan herhangi bir 80 veya 512 gig eski sürücüyü düşünelim).
Sabit sürücü, alanı bayt bayt olarak nasıl adresleneceğini bilmiyor; koşullu olarak bloklara bölünmüş durumda. Blok numaralandırması 0'dan başlar. (Buna LBA denir, ayrıntılar burada: )
Şekilde görüldüğü gibi LBA bloklarını HDD seviyesi olarak belirledim. Bu arada, diskinizin hangi blok boyutuna sahip olduğunu şu şekilde görebilirsiniz:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512Yukarıdaki düzey, tüm disk için bir bölümdür (yine basitlik açısından). Çoğu zaman iki tür bölüm işaretlemesi kullanılır: msdos ve gpt. Buna göre msdos, 2 TB'a kadar diskleri destekleyen eski bir formattır, gpt ise 1 zettabyte'a kadar 512 byte'lık blokları adresleyebilen yeni bir formattır. Bizim durumumuzda msdos türünde bir bölümümüz var, şekilden de görülebileceği gibi bölüm 1 numaralı blokla başlıyor, MBR için sıfır kullanılıyor.
Bir ext2 dosya sistemi oluşturduğum ilk bölümde, varsayılan blok boyutu 4096 bayttır ve bu da şekilde yansıtılmıştır. Dosya sistemi blok boyutunu şu şekilde görüntüleyebilirsiniz:
root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: a600bf40-f660-41f6-a3e6-96c303995479
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 65536
Block count: 261888
Reserved block count: 13094
Free blocks: 257445
Free inodes: 65525
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 63
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Fri Aug 2 15:02:13 2019
Last mount time: n/a
Last write time: Fri Aug 2 15:02:14 2019
Mount count: 0
Maximum mount count: -1
Last checked: Fri Aug 2 15:02:13 2019
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Default directory hash: half_md4
Directory Hash Seed: c0155456-ad7d-421f-afd1-c898746ccd76İhtiyacımız olan parametre “Blok boyutu”dur.
Şimdi ilginç olan kısım /home/serp/testfile dosyasının nasıl okunacağıdır? Bir dosya, verilerinin depolandığı bir veya daha fazla dosya sistemi bloğundan oluşur. Dosya adını bilmek, nasıl bulunur? Hangi blokları okumalıyım?
İnode'ların kullanışlı olduğu yer burasıdır. Ext2fs dosya sistemi, tüm inode'lara ilişkin bilgileri içeren bir "tabloya" sahiptir. Ext2fs durumunda inode sayısı dosya sistemi oluşturulurken ayarlanır. Tune2fs çıkışının “Inode count” parametresinde gerekli sayılara bakıyoruz yani. 65536 parçamız var. İnode ihtiyacımız olan bilgiyi içerir: aradığımız dosyaya ilişkin dosya sistemi bloklarının listesi. Belirli bir dosyanın inode numarası nasıl bulunur?
Karşılık gelen ad ve inode numarası dizinde bulunur ve ext2fs'deki dizin özel bir dosya türüdür; ayrıca kendi inode numarasına sahiptir. Bu kısır döngüyü kırmak için kök dizine “sabit” bir inode numarası “2” atandı. 2 numaralı inode'un içeriğine bakalım:
root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (4-Feb-2014)
debugfs: stat <2>
Inode: 2 Type: directory Mode: 0755 Flags: 0x0
Generation: 0 Version: 0x00000000:00000002
User: 0 Group: 0 Size: 4096
File ACL: 0 Directory ACL: 0
Links: 3 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5d43cb51:16b61bcc -- Fri Aug 2 16:34:09 2019
atime: 0x5d43c247:b704301c -- Fri Aug 2 15:55:35 2019
mtime: 0x5d43cb51:16b61bcc -- Fri Aug 2 16:34:09 2019
crtime: 0x5d43b5c6:00000000 -- Fri Aug 2 15:02:14 2019
Size of extra inode fields: 28
BLOCKS:
(0):579
TOTAL: 1Gördüğünüz gibi, ihtiyacımız olan dizin 579 numaralı blokta yer alıyor. İçinde ana klasörün düğüm numarasını bulacağız ve serp dizininde istenen dosyanın düğüm numarasını görene kadar zincir boyunca böyle devam edeceğiz. Aniden birisi numaranın doğru olup olmadığını ve gerekli bilgilerin orada olup olmadığını kontrol etmek isterse, bu zor değildir. Yaparız:
root@ubuntu:/# dd if=/dev/sdb1 of=/home/serp/dd_image bs=4096 count=1 skip=579
1+0 records in
1+0 records out
4096 bytes (4,1 kB) copied, 0,000184088 s, 22,3 MB/s
root@ubuntu:/# hexdump -c /home/serp/dd_imageÇıktıda dizindeki dosyaların adlarını okuyabilirsiniz.
Böylece asıl soruya geliyorum: “Hangi sebeplerden dolayı kayıt hatası meydana gelebilir?”
Doğal olarak bu, dosya sisteminde boş blok kalmaması durumunda gerçekleşecektir. Bu durumda ne yapılabilir? Açıkça görülen "gereksiz her şeyi silin"in yanı sıra, ext2,3 ve 4 dosya sistemlerinde "Ayrılmış blok sayısı" diye bir şeyin olduğunu da unutmamalısınız. Yukarıdaki listeye bakarsanız “13094” şeklinde bloklarımız var. Bunlar yalnızca root kullanıcı tarafından yazılabilen bloklardır. ancak sorunu hızlı bir şekilde çözmeniz gerekiyorsa, geçici bir çözüm olarak bunları herkesin kullanımına sunarak bir miktar boş alan elde edebilirsiniz:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)Onlar. Varsayılan olarak disk alanının %5'i yazmaya müsait değildir ve modern disklerin hacmi göz önüne alındığında bu yüzlerce gigabayt olabilir.
Başka ne olabilir? Serbest blokların olması da mümkündür, ancak artık düğüm yoktur. Bu genellikle dosya sisteminizde dosya sistemi blok boyutundan daha küçük bir grup dosyanız varsa meydana gelir. 1 dosya veya dizine 1 inode harcandığını ve toplamda (belirli bir dosya sistemi için) 65536'ya sahip olduğumuzu düşünürsek, durum gerçekçi olmaktan da ötedir. Bu, df komutunun çıktısından açıkça görülebilir:
serp@ubuntu:~$ df -hi
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 493K 480 492K 1% /dev
tmpfs 493K 425 493K 1% /run
/dev/xvda1 512K 240K 273K 47% /
none 493K 2 493K 1% /sys/fs/cgroup
none 493K 2 493K 1% /run/lock
none 493K 1 493K 1% /run/shm
none 493K 2 493K 1% /run/user
/dev/xvdc1 320K 4,1K 316K 2% /var
/dev/xvdb1 64K 195 64K 1% /home
/dev/xvdh1 4,0M 3,1M 940K 78% /var/www
serp@ubuntu:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 2,0G 4,0K 2,0G 1% /dev
tmpfs 395M 620K 394M 1% /run
/dev/xvda1 7,8G 2,9G 4,6G 39% /
none 4,0K 0 4,0K 0% /sys/fs/cgroup
none 5,0M 0 5,0M 0% /run/lock
none 2,0G 0 2,0G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/xvdc1 4,8G 2,6G 2,0G 57% /var
/dev/xvdb1 990M 4,0M 919M 1% /home
/dev/xvdh1 63G 35G 25G 59% /var/www/var/www bölümünde açıkça görülebileceği gibi, dosya sistemindeki boş blokların sayısı ve boş düğümlerin sayısı büyük ölçüde farklılık gösterir.
Eğer inode'ların biterse sana herhangi bir büyü söylemeyeceğim çünkü... hiçbiri yok (yanılıyorsam bana bildirin). Bu nedenle, küçük dosyaların çoğaldığı bölümler için dosya sistemini akıllıca seçmelisiniz. Örneğin, btrfs inode'ları sona eremez çünkü Gerektiğinde dinamik olarak yenileri oluşturulur.
Kaynak: habr.com