GNU/Linux >> Znalost Linux >  >> Linux

Vztah inodů, Lba, logických objemů, bloků a sektorů?

Trochu se stydím položit tuto otázku, ale rád bych viděl diagram, který ukazuje, jak spolu souvisí následující věci. Bylo by hezké, kdyby diagram zahrnoval také jakékoli transformace potřebné k mapování mezi různými vrstvami.

Pokud tomu dobře rozumím, domnívám se, že spolu souvisí následujícím způsobem, ale nejsem si jistý, zda je mé porozumění 100% přesné.

                           .-----------------.
                           |      inode      |
                           '-----------------'
                                    |
                           .-----------------.
                           |      EXT4       |
                           '-----------------'
                                    |
                         .---------------------.
                         | logical volume (LV) | --- part of LVM
                         '---------------------'
                                    |
                          .-------------------.
                          | volume group (VG) |  --- part of LVM
                          '-------------------'
                                    |
                            .---------------.
                            | /dev/<device> |
                            '---------------'
                                    |
                   .--------------------------------.
                   | Logical Block Addressing (LBA) |
                   '--------------------------------'
                                    |
                           .-----------------.
                           | blocks/sectors  |
                           '-----------------'
                                    |
                                   HDD     
                                _.-----._  
                              .-         -.
                              |-_       _-|
                              |  ~-----~  |
                              |           |
                              `._       _.'
                                 "-----"   

Odkazy

  • Zjištění, které sektory pevného disku zabírají soubor
  • Identifikující soubor spojený s nečitelným sektorem disku
  • Špatný blok HOWTO pro smartmontools
  • C5170 Poznámky k přednášce — Interní reprezentace souborů – Unixový souborový systém
  • Logické adresování bloku
  • Rozvržení disku Ext4

Přijatá odpověď:

způsob tl;dr

Váš diagram je v podstatě správný.

/dev/<device> soubory

Myslím, že nejzákladnějším způsobem, jak začít odpovídat na vaši otázku, je to, co /dev/<device> soubory jsou. Řekněme, že máte pevný disk. Tento pevný disk má tabulku oddílů založenou na MBR a má dva oddíly, jeden naformátovaný na ext4 s nějakými soubory a druhý nastavený pro LVM. Všimněte si, že tato odpověď hovoří o vytváření souborů zařízení za běhu, což znamená, že používáte linuxové jádro. Na jiných Unices jsou věci trochu jiné.

Když připojíte tento pevný disk (nebo když ho systém detekuje při spouštění), vytvoří se soubor zařízení v /dev adresář – obecně se nazývá buď /dev/sd* nebo /dev/hd* (podle toho, jaký řadič je použit k připojení disku) – * je písmeno. Bajty v souboru zařízení jsou v podstatě lineárně mapovány na bajty na fyzickém disku:pokud použijete nástroj pro zápis na začátek souboru zařízení, budou tato data zapsána také na fyzický začátek fyzického disku.

Nyní systém také rozumí tabulkám oddílů, jako jsou MBR a GPT. Jakmile bude vytvořen počáteční soubor zařízení, bude přečten, aby se zjistilo, zda má tabulku oddílů. Pokud ano, vytvoří se soubory zařízení představující tyto oddíly. Tedy za předpokladu, že původní soubor zařízení se jmenoval /dev/sda , soubor zařízení s názvem /dev/sda1 bude vytvořen (představující první oddíl ve formátu ext4) a také /dev/sda2 zařízení (představující druhý oddíl LVM). Ty jsou namapovány lineárně na příslušné oddíly stejným způsobem jako celý disk – to znamená, pokud použijete nástroj pro (například) zápis na začátek /dev/sda2 , zapsaná data budou fyzicky zapsána na začátek druhého oddílu, který je ve skutečnosti prostřední celého disku, protože tam začíná druhý oddíl.

Bloky a sektory

Nyní je vhodný čas mluvit o blocích a sektorech:toto jsou jen měření prostoru na fyzickém disku, nic víc (alespoň pokud tomu dobře rozumím). Sektor je fyzická oblast na pevném disku; je to obvykle 512 bajtů – 4 kB na novějších pevných discích. Blok je také měrnou jednotkou, téměř vždy má 8 KB. Když někdo mluví o čtení a zápisu bloků, znamená to jen to, že namísto čtení každého bajtu dat jednotlivě, čte a zapisuje data v blocích po 8 KB.

Systémy souborů a inody

Další na řadě jsou souborové systémy a inody. Souborový systém je poměrně jednoduchý koncept:na začátku oblasti, ve které se souborový systém nachází (tato oblast je obvykle oddíl), je spousta informací o souborovém systému. Tato hlavička (také označovaná jako superblok, domnívám se) se nejprve používá k určení, který ovladač souborového systému by měl být použit ke čtení souborového systému, a poté je použit vybraným ovladačem souborového systému ke čtení souborů. Toto je samozřejmě zjednodušení, ale v zásadě ukládá dvě věci (které mohou nebo nemusí být uloženy jako dvě odlišné datové struktury na disku, v závislosti na typu fs):strom adresářů a seznam inodů. Strom adresářů je to, co vidíte, když uděláte ls nebo tree . Strom adresářů uvádí, které soubory a adresáře jsou potomky kterých jiných adresářů. Vztah rodič-podřízený soubor/adresář tvoří strom adresářů UNIX, jak jej známe.

Související:Freebsd – ssh v chrootovaném vězení nefunguje, protože operace /dev/null není podporována?

Ale adresářový strom obsahuje pouze jména. Tato jména jsou navíc spojena s čísly inodů. Číslo inodu obsahuje informace, například kde jsou části souboru fyzicky uloženy na disku. Inode sám o sobě je prostě „soubor“ bez jména; inode je spojen se jménem prostřednictvím stromu adresářů. Viz také Co je to Superblock, Inode, Dentry a File?

Zatím máme následující vysvětlení:/dev/sd* mapování souborů na pevné disky, /dev/sd*# mapování souborů na číslo oddílu # na /dev/sd* . Souborový systém je datová struktura na disku, která sleduje adresářový strom; obecně je uchováván v oddílu (/dev/sd*# ). Souborový systém obsahuje inody; inody jsou čísla, která představují soubory spolu s daty přidruženými k těmto souborům (kromě jejich názvu a pozice ve stromu adresářů).

Stojí za zmínku, že souborové systémy obecně sledují data v blocích. Obvykle je adresářový strom a seznam inodů uložen v blocích, nikoli v bajtech, a inody ukazují na bloky na disku, nikoli na bajty. (To může způsobit problémy, kdy soubory obvykle plýtvají půl blokem místa, protože souborový systém alokoval celý blok, ale nemusel použít celý blok pro poslední část souboru.)

Mapovač zařízení

Posledním kouskem skládačky je velmi důležitý modul v jádře Linuxu nazvaný mapovač zařízení (načtěte jej pomocí modprobe dm ). Mapovač zařízení vám v podstatě umožňuje vytvořit další soubor zařízení v /dev/mapper adresář. Tento soubor zařízení je poté namapován na jiný zdroj dat, který se může v procesu transformovat. Nejjednodušším příkladem je čtení části souboru.

Řekněme, že máte obraz celého disku s tabulkou oddílů. Potřebujete načíst data z jednoho z oddílů v obraze, ale nemůžete se dostat jen tento oddíl, protože se jedná o obraz celého disku namísto obrazu jednoho oddílu. Řešením je najít, kde v bitové kopii je váš oddíl, a poté vytvořit nový soubor zařízení mapující tuto část obrazu disku. Zde je schéma:

.-------------------.
|  /dev/mapper/foo  | <- This is the device file created with the device mapper
.___________________.
                   /
                  /
                 /   <- This is a small section of the image being mapped to
                /         the new device file
               /
              /
 .------------------.
 |  diskimage.img   | <- This is the full-disk image. It's a regular file.
 .__________________.     Notice how the mapping goes to _part_ of the file.

Jiný způsob, jak si to představit, je jako transformační potrubí (toto je přesnější metafora pro to, co se děje uvnitř jádra). Představte si dopravní pás. Požadavek – čtení, zápis atd. – začíná na jednom konci dopravního pásu v souboru zařízení vytvořeném pomocí mapovače zařízení. Požadavek poté prochází transformací mapovače zařízení do zdrojového souboru. Ve výše uvedeném příkladu je tímto zdrojovým souborem běžný soubor diskimage.img . Zde je schéma:

Read operation goes onto
device mapper conveyor belt

read()                                      The device mapper transforms the read         The modified read request finally
                                           request by moving the requested region        reaches the source file, and the data
            Beginning of conveyor belt     to read forward by some number of bytes.      is retrieved from the filesystem.
         
            .-------------------.          .--------------------------.                  .------------------------.
            |  /dev/mapper/foo  |          |   Transformation logic   |                  | /path/to/diskimage.img |
            .___________________.          .___+_____+_____+_____+____.                  .________________________.
        -->                                             
             ---------------------------------------------------------------------------------------------------------------
             o          o          o          o          o          o          o          o          o          o          o

Všimněte si, že v diagramu má transformační logika, která byla propojena s mapovačem zařízení, malé nástroje (+ s) manipulovat s požadavkem na čtení, když se pohybuje na dopravním pásu.

Související:Pamatujete si napůl napsaný příkaz, když něco zkontroluji?

Teď se mi moc nechce kopírovat ten diagram a upravovat ho pro LVM, ale v zásadě může být transformační část cokoli – nejen posunutí rozsahu bajtů dopředu. LVM funguje takto:Fyzický rozsah LVM je součástí LVM, která je umístěna na disku a sleduje, kde jsou data. Představte si to jako souborový systém LVM. V metafoře běžícího pásu je fyzický rozsah jedním ze zdrojových souborů a transformace spočívá v tom, že LVM dělá svou věc a mapuje požadavek na logický svazek (což je položka zcela vlevo na dopravním pásu) na fyzická data na disku. Když už jsme u toho…

Na své koncepty LVM jsem trochu zrezivělý, ale IIRC, skupina svazků, je v podstatě jako disk v LVM. Opět platí, že IIRC, úrovně RAID atd. jsou spravovány podle skupiny svazků. Logický svazek je tedy jako oddíl a logické svazky jsou vlastně soubory zařízení, které je představují. Souborové systémy a podobně umístíte na logické svazky.

Skvělá věc na mapovači zařízení je, že logiku, která je s ním postavena, lze libovolně vkládat do datového zásobníku – vše, co musíte udělat, je změnit název zařízení, které čtete. Takto fungují šifrované oddíly (ne šifrovací schémata, která fungují na úrovni souborů – používají FUSE), a takto funguje LVM. V tuto chvíli mě nenapadají žádné další příklady, ale věřte mi, že mapovač zařízení je docela špatný.

Logické blokové adresování

Nikdy jsem o tom neslyšel, takže o tom nemohu poskytnout žádné informace. Doufám, že někdo přijde a upraví tuto odpověď.


Linux
  1. seznam zařízení přidružených k logickým svazkům bez použití příkazů balíčku lvm2

  2. Jaký je rozdíl mezi partx a kpartx?

  3. MegaCli:Získejte název zařízení /dev/sd* pro logickou jednotku

  1. Rozdíl mezi [[ $a ==Z* ]] a [ $a ==Z* ]?

  2. Linux – Sysfs a Devtmpfs?

  3. Linux – Jak linuxové jádro zná hlavní a vedlejší čísla zařízení?

  1. Přednost logických operátorů Shell &&, ||?

  2. Vztah mezi typy mime a příponami souborů .

  3. Jaký je rozdíl mezi ovladačem platformy Linux a normálním ovladačem zařízení?