A Linux fájlrendszer leggyakrabban ext4. Ez naplóz, és lehetővé teszi, hogy kényelmesen dolgozzon az adatokkal a feladatok túlnyomó többségének megoldása során. Vannak azonban mások is. Főbb típusok fájlrendszerekés a velük való munka alapelveit ennek az anyagnak a keretein belül tekintjük át.
A megkülönböztető jellemzők a fájlokkal való munka sebessége, a biztonság és a paraméterek (például blokkméret), amelyek alapértelmezés szerint léteznek, és az FS létrehozásakor kerülnek beállításra. Talán a legtöbbet fontos jellemzője egy rönk jelenléte. A rendszernapló rögzíti az adatokat ill metaadatokat(csak fejlécek), amelyekből hiba esetén visszaállíthatók az információk.
Fájlrendszer bármilyen eszközön létrehozható: lemezen vagy rendszerpartíción.
Az EXT2 egy mára elavult fájlrendszer, amelyet a modern telepítésekben alig használnak. a fő hátrány a naplózás hiánya, ami ennek megfelelően meghibásodás esetén lehetetlenné teszi az adatok visszaállítását. Még mindig vonatkozik hordozható adathordozók információk, például az USB. A tár nem szükséges hozzájuk, mivel bizonyos helyet foglal el.
A maximális sebességet is garantálja.
Elmozdított EXT2, fő jellemzője a magazin megjelenése, visszafelé teljesen kompatibilis az EXT2-vel (az EXT2 szabadon konvertálható EXT3-ra). Ma már ez is ritka, szinte mindig az EXT4-et használják.
A napló egy speciális memóriaterület, amely minden változásról információt rögzít.
Három lehetőség van a naplózásra (a fájlrendszer létrehozásakor megadva):
Leggyakrabban a kiterjesztett fájlrendszer modern verzióját használják
EXT4-ben a naplózás az opció beállításával kikapcsolható adat amikor be van szerelve ki
A fájlrendszert az mk2fs parancs hozza létre
A kívánt naplózási beállítás a felszereléskor kerül megadásra, például:
mount /dev/vdc /mnt/1 -t ext3 -o data=journal
Konvertálás EXT2 E-ről XT3-ra
A ReiserFS (és a Reiser4 modern megvalósítása SELinux támogatással) jól teljesít és nagyon produktív – különösen, ha nagyszámú kis fájllal dolgozik. A ReiserFS nem osztja ki az inode-okat az egyes kis fájlokhoz úgy, hogy azokat együtt dolgozza fel, hanem a ReiserFS is egy naplót használ több lehetőséggel. Jelenleg a fájlrendszert oroszországi fejlesztők támogatják.
A paranccsal létrehozhat egy FS-t egy eszközhöz
Az XFS egy naplózott fájlrendszer. RAM-ot használ az információk tárolására, így lehetséges az adatvesztés – például az áramellátás kikapcsolásakor.
Az XFS Ubuntuban való használatához csomagokat kell telepítenie xfsprogsÉs xfsdump
A Linux fájlrendszer Windows környezetben is létezik. Akkor használatos, ha meg kell szervezni a különböző operációs rendszerű kliensek bizonyos lemezeihez és partícióihoz való közös hozzáférést. Más esetekben nem ajánlott használni, mert nehéz lehet Linux alatt dolgozni.
VLADIMIR MESKOV
ext2 fájlrendszer architektúra
A cikk az ext2 - a fájlrendszer - logikai felépítését tárgyalja operációs rendszer Linux.
Az ext2 fájlrendszer alapvető összetevői
Mint minden UNIX fájlrendszerben, az ext2 fájlrendszerben is a következő összetevők különböztethetők meg:
Blokkok és blokkcsoportok
A teljes lemezpartíció fix méretű blokkokra van osztva, amelyek a szektorméret többszörösei - 1024, 2048 és 4096 bájt. A blokk mérete a partíción lévő fájlrendszer létrehozásakor kerül megadásra merevlemez. A kisebb blokkméret helyet takarít meg a merevlemezen, de korlátozza a fájlrendszer maximális méretét is. Minden blokknak van sorozatszáma. A töredezettség és a merevlemez fejmozgások számának csökkentése érdekében nagy adattömbök olvasásakor a blokkokat csoportokba egyesítik.
Információs csomópont
A fájlrendszer alapkoncepciója egy információs csomópont, információs csomópont vagy inode. Ez egy speciális struktúra, amely információkat tartalmaz egy fájl attribútumairól és fizikai helyéről. A fájl attribútumai a típusa (normál fájl, könyvtár stb.), a hozzáférési jogosultságok, a tulajdonos azonosítója, mérete, létrehozási ideje. A fizikai hely információ fájladatokat tartalmazó abszolút blokkszámok sorozata.
Superblock
A szuperblokk az ext2 fájlrendszer fő eleme. A következő információkat tartalmazza a fájlrendszerről (a lista nem teljes):
Más szóval, ez a szuperblokkot tartalmazó blokk száma. Ez a szám mindig 0, ha a fájlrendszer blokkmérete nagyobb, mint 1024 bájt, és 1, ha a blokk mérete 1024 bájt.
A fájlrendszer állapota közvetlenül függ a szuperblokk integritásától. Az operációs rendszer több biztonsági mentések szuperblokk, hogy sérülés esetén helyreállítható legyen. A főpéldány 1024 bájtnyi eltolásban található annak a partíciónak a kezdetétől, amelyen a fájlrendszer létrejött (az első 1024 bájt az operációs rendszer betöltője számára van fenntartva).
Az ext2 fájlrendszer korai verziói szuperblokk-másolatokat hoztak létre minden blokkcsoport elején. Ez nagy lemezterület-veszteséget eredményezett, így később a szuperblokk-mentések száma csökkent, és a 0, 1, 3, 5 és 7 blokkcsoportokat jelölték ki ezek befogadására.
Blokkcsoport formátuma
ábrán látható az ext2 fájlrendszer általánosított blokkdiagramja. 1.
Szinte minden blokkcsoportnak azonos a formátuma. Minden csoportban az információs blokkok mellett bittérkép formájában tárolják a csoport blokkjainak és inódjainak foglaltságára vonatkozó információkat. A 0. blokkcsoport egy szuperblokkot és egy csoportleíró táblázatot is tartalmaz, amelyeket az alábbiakban tárgyalunk.
A blokk foglalt bittérkép általában a csoport első blokkjában található. Ha a csoportban van tartalék szuperblokk, akkor a bittérkép a csoport második blokkjában található. A bittérkép mérete egy blokk. Ennek a térképnek minden bitje a blokk állapotát jelzi. Ha a bit be van állítva (1), akkor a blokk foglalt, ha visszaállítja (0), akkor a blokk szabad. A csoport első blokkja a térkép nulla bitjének, a második blokk az első bitnek felel meg, és így tovább.
Az azonos csoporton belüli inódákat egy táblázatba gyűjtjük. Egy csoport inode foglaltsági bittérképében minden bit egy elem állapotát jelenti a csoport inode táblájában.
Minden blokkcsoportot egy blokkcsoport-leíró ír le. A csoportleíró egy olyan struktúra, amely információkat tartalmaz a megfelelő csoport blokk foglalt bittérképének, foglalt inode bittérképének és inode táblájának címeiről. Az összes csoportleírót egy csoportleíró táblában gyűjtjük össze, amelyet a 0. blokkcsoportban tárolunk. A szuperblokkhoz hasonlóan az operációs rendszer biztonsági másolatot készít a csoportleíró tábláról.
Fájlolvasási algoritmus
Minden inode, mint egy blokk, rendelkezik egy sorszámmal, amely egyedi a fájlrendszeren belül, és csak egy fájlról tartalmaz információt. Így egy fájl tartalmához való hozzáféréshez ismerni kell a hozzá tartozó inode sorszámát.
Mint fentebb említettük, a fájl fizikai helyére vonatkozó információkat az inode tartalmazza. Ez az információ a fájladatokat tartalmazó 32 bites blokkszámok sorozata (1. ábra). Az első 12 szám közvetlen hivatkozás az információs blokkokhoz (közvetlen blokkszám). A 13. szám egy közvetett blokkszám. A blokk címét tartalmazza, amely az információs blokkok címeit tárolja. A 14. szám egy dupla indirekt link (dupla blokkszám), a 15. szám egy hármas közvetett kapcsolat (hármas blokkszám).
A fájlnév nem része az inode-nak, a fájlnevek és az inode sorszámok közötti leképezés könyvtárakon keresztül történik.
Katalógusok
A UNIX és POSIX rendszereken található fájlok egy faszerű hierarchikus fájlrendszerben tárolódnak. A fájlrendszer gyökere a gyökérkönyvtár, amelyet a "/" szimbólum jelöl. A fájlrendszerfa minden köztes csomópontja egy könyvtár. A fájlrendszerfa levélcsomópontjai vagy üres könyvtárak vagy fájlok. A fájl abszolút elérési útja a megadott fájlhoz vezető összes könyvtár nevéből áll, a gyökérkönyvtártól kezdve. Például a /home/test.file elérési út azt jelenti, hogy a test.file fájl a kezdőkönyvtárban található, amely viszont a gyökérkönyvtárban található "/".
A könyvtárakat, akárcsak a fájlokat, inode írja le. A könyvtár tartalma bejegyzések tömbje, amelyek mindegyike az aktuális könyvtárban "belül" lévő fájlról tartalmaz információt.
A címtárbejegyzés formátuma a következő:
A fájl inode-számának keresése mindig a gyökérkönyvtárban kezdődik. Például a gyökérkönyvtárban található fájl inode számának lekéréséhez az operációs rendszernek be kell szereznie a gyökérkönyvtár tartalmát, meg kell találnia benne egy bejegyzést a fájl nevével, és ebből a bejegyzésből ki kell bontania a fájl inode számát. .
Az első néhány inode-ot a fájlrendszer lefoglalja, és a fejlécfájlban vannak felsorolva:
*Speciális inode számok
#define EXT2_BAD_INO 1 /* Hibás blokkok inode */
#define EXT2_ROOT_IN 2 /* Root inode */
#define EXT2_ACL_IDX_IN 3 /* ACL inode */
#define EXT2_ACL_DATA_INO 4 /* ACL inode */
#define EXT2_BOOT_LOADER_INO 5 /* Boot loader inode */
#define EXT2_UNDEL_DIR_INO 6 /* Inode könyvtár törlésének visszavonása */
A 2. számú inode (root inode) a gyökérkönyvtár bejegyzés számára van fenntartva. Ez az inode a 0. blokkcsoportban található, és a második pozíció a csoport inode táblájában. Az első lefoglalt inode száma a szuperblokkban tárolódik.
Miután meghatározta a fájl inode sorszámát, a kernel kiszámítja annak a csoportnak a számát, amelyben ez az inode található, és annak helyét a csoport inode táblájában. Ebből az inode pozícióból olvasva az operációs rendszer teljes információt kap a fájlról, beleértve azon blokkok címét is, amelyekben a fájl tartalma tárolva van.
A blokkcsoport számát, amelyben az inode található, a következő képlettel számítjuk ki:
csoport = (inode_szám - 1) / inodes_per_group
Ahol:
Az inode pozícióját a csoport inode táblázatában a következő képlet határozza meg:
index = (inode_szám - 1) % inodes_per_groupe
ahol az index az inode pozíciója a táblázatban.
Vegyünk egy példát a gyökérkönyvtárban található test.file fájl tartalmának lekérésére. A /test.file fájl olvasásához a következőket kell tennie:
ábrán. A 2. ábra a /test.file olvasásának lépéseit mutatja be részletesen.
1-6 lépések – a gyökérkönyvtár olvasása:
Az inode szám megadásával elérhetők a fájl információs blokkjai (7-11. lépések):
A fájlolvasási algoritmus szoftveres megvalósítása
Kezdeti adatok: van egy merevlemez-partíció, amelyen az ext2 fájlrendszer létrejön. Ez a partíció a /dev/hda3 eszközfájlnak felel meg. A home alkönyvtár a partíció gyökérkönyvtárában lett létrehozva, és a következő tartalommal tartalmazza a test.file fájlt:
A citrusfélék élnének a déli bozótosban?
Igen, de hamis másolat!
1234567890-=
Ne gondolj rosszra, ez nem hülyeség, hanem próbagyakorlat a volt Szovjetunió jelzőcsapatainak távíró-kezelői tanfolyamáról!
Figyelem! Figyelembe kell venni fontos pont. A létrehozott fájl nem kerül azonnal a lemezre, hanem először a lemez pufferébe kerül. A fájl tartalmának azonnali lekérésére tett kísérlet a fenti algoritmussal nem vezet semmire, mivel a lemezen fizikailag nincs információ erről a fájlról. „Kényszeríteni” kell a rendszert, hogy a lemezpuffert lemezre írja. Ennek legegyszerűbb módja az újraindítási művelet végrehajtása. Ezért a fájl létrehozása után indítsa újra a rendszert.
A feladatunk az, hogy a /dev/hda3 eszközfájl segítségével olvassuk be a /home/test.file fájlt, közvetlenül hozzáférve az információs blokkjaihoz.
Fontolja meg a műveletet végrehajtó modul szoftveres megvalósítását.
Fejléc fájlok:
#beleértve
#beleértve
#beleértve
#beleértve
#beleértve
#beleértve
A fejlécfájl olyan szerkezeti típusokat határoz meg, amelyek leírják az ext2 fájlrendszer fő összetevőit - szuperblokk, blokkcsoport-leíró, információs csomópont, könyvtárbejegyzés.
Tekintsük röviden azokat a mezőket, amelyeket ezek a struktúrák tartalmaznak:
Az EXT2_N_BLOCKS értéke a következő fájlban van megadva:
* Az adatblokkokhoz viszonyított állandók
#define EXT2_NDIR_BLOCKS 12
#define EXT2_IND_BLOCK EXT2_NDIR_BLOCKS
#define EXT2_DIND_BLOCK (EXT2_IND_BLOCK + 1)
#define EXT2_TIND_BLOCK (EXT2_DIND_BLOCK + 1)
#define EXT2_N_BLOCKS(EXT2_TIND_BLOCK + 1)
#define EXT2_NAME_LEN 255
Határozzuk meg a partíció nevét, amelyen a fájlrendszer létrejött, a globális struktúrákat és a változókat.
#define PART_NAME "/dev/hda3"
struct ext2_super_block sb;
/* puffer a csoportleíró táblázat tárolására */
unsigned char buff_grp;
unsigned char buff; /* információs puffer */
int indev; /* eszközfájl-leíró */
int BLKSIZE; /* fájlrendszer blokk mérete */
Határozunk meg néhány funkciót, amelyek működéséhez szükségünk van:
Superblock olvasási funkció:
void read_sb()
memset(&sb,0,1024);
1024 bájtot tolunk el a szakasz elejétől, és beolvassuk a szuperblokkot a struct ext2_super_block sb struktúrába:
If(lseek(indev;1024;0)< 0) {
error("lseek");
Kilépés(-1);
If(read(indev,(char *)&sb,sizeof(sb))< 0) {
error("olvasás");
Kilépés(-1);
A fájlrendszer azonosítójának ellenőrzése:
If(sb.s_magic != EXT2_SUPER_MAGIC) (
Printf("Ismeretlen fájlrendszer típus!");
Kilépés(-1);
Az EXT2_SUPER_MAGIC értéket a fejlécfájl határozza meg.
Információkat jelenítünk meg a szuperblokkban lévő fájlrendszerről:
printf(" Superblock info ----------- ");
Printf("Inodes count - %u ",sb.s_inodes_count);
Printf("Blokkszám - %u ",sb.s_blocks_count);
Printf("Blokkméret - %u ",1024<< sb.s_log_block_size);
Printf("Első inode - %d ",sb.s_first_ino);
Printf("Magic - 0x%X ",sb.s_magic);
Printf("Inode mérete - %d ",sb.s_inode_size);
Printf("Inódok csoportonként - %u ",sb.s_inodes_per_group);
Printf("Blokok csoportonként - %u ",sb.s_blocks_per_group);
Printf("Első adatblokk - %u ",sb.s_first_data_block);
Visszatérés;
Csoportleíró táblázat olvasási funkciója:
void read_gdt()
Számítsa ki a fájlrendszer blokkméretét:
BLKSIZE = 1024<< sb.s_log_block_size
A csoportleíró tábla az első adatblokkot közvetlenül követő blokkban (a szuperblokk mögött) található.
A táblázat olvasása:
If(lseek(indev, (sb.s_first_data_block + 1) * BLKSIZE, 0)< 0) {
error("lseek");
Kilépés(-1);
If(read(indev,buff_grp,BLKSIZE)< 0) {
error("olvasás");
Kilépés(-1);
Visszatérés;
A függvény, amely egy inode tartalmát a száma alapján kapja meg:
void get_inode(int inode_num, struct ext2_inode *in)
A függvény bemeneti paraméterei az inode száma és a struct ext2_inode struktúra.
Struct ext2_group_desc gd;
U64 csoport, index, poz.
Kiszámoljuk annak a blokkcsoportnak a számát, amelyben az inode_num sorszámú inode található:
Csoport = (inode_szám - 1) / sb.s_inodes_per_group;
Bontsa ki a csoportleírót a csoportleíró táblából, és másolja a struct ext2_group_desc gd szerkezetébe:
Memset((void *)&gd, 0, sizeof(gd));
Memcpy((void *)&gd, buff_grp + (csoport * (sizeof(gd))), sizeof(gd));
Kiszámoljuk az inode_num sorszámú inode pozícióját a csoportcsoport inode táblájában, és beolvassuk ezt az inode-ot az ext2_inode struktúrába:
index = (inode_szám - 1) % sb.s_inodes_per_group;
Pos = ((__u64)gd.bg_inode_table) * BLKSIZE + (index * sb.s_inode_size);
Preread64(indev, in, sb.s_inode_size, pos);
Visszatérés;
Adatblokk olvasási funkciója:
void read_iblock(struct ext2_inode *in, int blk_num)
U64pos;
A függvény bemeneti paraméterei az inode struktúra és a blokkszám (értsd: az inode-ban található címblokkok sorozatából származó szám).
Kiszámoljuk az eltolást a partíció információs blokkjához, és beolvassuk ezt a blokkot a globális pufferbe:
Pos = ((__u64)in->i_block) * BLKSIZE;
Preread64(indev, buff, BLKSIZE, poz);
Visszatérés;
A gyökérkönyvtár tartalmának lekérésére szolgáló függvény:
void get_root_dentry()
Az ext2_inode szerkezete in;
A gyökérkönyvtár inode száma ismert, ezért megkapjuk a gyökérkönyvtár inode tartalmát, és beolvassuk a tartalmát a puffer pufferbe:
get_inode(EXT2_ROOT_INO, &in);
Read_iblock(&in, 0);
A puffer puffer tartalmazza a gyökérkönyvtár tartalmát.
Visszatérés;
Funkció az inode szám lekéréséhez a fájlnévből:
int get_i_num(char *name)
A függvény bemeneti paraméterei a fájlnév. A visszatérési érték a fájl inode száma.
int i = 0, rec_len = 0;
Struct ext2_dir_entry_2dent;
A puffer puffer könyvtárbejegyzések tömbjét tartalmazza. Egy fájl inode számának meghatározásához meg kell találnia egy bejegyzést ebben a tömbben a fájl nevével:
For(; i< 700; i++) {
Memcpy((void *)&dent, (buff + rec_len), sizeof(dent));
If(!memcmp(dent.name, name, dent.name_len)) break;
Rec_len += dent.rec_len;
Return dent.inode;
Most írjuk fel a fő függvényt:
int main()
Változók és struktúrák:
struct ext2_inode in;
// a fájl abszolút elérési útja
Unsigned char *full_path = "/home/test.file";
unsigned char buff1;
Statikus int i = 1;
int n, i_num, outf, type;
A fájl abszolút elérési útjában az első karakternek perjelnek (/) kell lennie. Nézzük meg:
If(teljes_útvonal != "/") (
error("perjel");
Kilépés(-1);
Nyissa meg az eszközfájlt, olvassa el a szuperblokk- és csoportleíró táblázatot:
indev = open(PART_NAME,O_RDONLY);
if(indev< 0) {
error("nyitva");
Kilépés(-1);
Read_sb();
Read_gdt();
Szerezd meg a gyökérkönyvtár tartalmát:
get_root_dentry();
A buff puffer mostantól a gyökérkönyvtár összes bejegyzését tartalmazza (ha szeretné, külön fájlba mentheti). Most, hogy megvannak a gyökérkönyvtár bejegyzései, a fenti fájlolvasási algoritmus segítségével elérhetjük a test.file tartalmát. Ennek érdekében ciklust szervezünk. A ciklus törzsében elemezzük a fájl abszolút elérési útját, kiemelve annak elemeit - alkönyvtárakat (van ilyenünk, home) és a kívánt fájl nevét (test.file). Minden elemhez meghatározzuk az inode sorszámát, kiolvassuk ezt az inode-ot, majd megkapjuk a nulla blokk tartalmát (az inode-ban található címblokkok sorozatából):
míg(1) (
memset(buff1,0,sizeof(buff1));
For(n = 0 ; n< EXT2_NAME_LEN; n++, i++) {
Buff1[n] = teljes_útvonal[i];
If((buff1[n] == "/") || (buff1[n] == "?")) (
I++;
szünet;
buff1[n] = "?";
A fájl abszolút elérési útjának minden eleméhez meghatározzuk az inode sorszámát, beolvassuk a memóriába, majd megkapjuk a nulla blokk tartalmát:
I_szám = get_i_num(buff1);
Get_inode(i_num, &in);
Read_iblock(&in, 0);
Mutassunk információkat a fájlról (név, inode száma, fájlméret és típus):
Printf("Inode szám - %u ", i_szám);
Printf("Fájlnév - %s ", buff1);
Printf("Fájlméret - %u ",in.i_size);
A fájltípust a struct ext2_inode struktúra i_mode mezőjének felső négy bitje határozza meg:
type = ((in.i_mode & 0xF000) >> 12);
Printf("Típus - %d ",típus);
kapcsoló(típus) (
Case (0x04):
Printf("(könyvtár)");
szünet;
Case (0x08):
Printf("(normál fájl)");
szünet;
Case (0x06):
Printf("(eszközfájl blokkolása)");
szünet;
Case (0x02):
Printf("(char eszközfájl) ");
szünet;
alapértelmezett:
Printf("(ismeretlen típus)");
szünet;
A fájl típusának ellenőrzése. Ha ez egy normál fájl, megtörjük a hurkot:
if(type & 0x08) (
A puffer puffer tartalmazza a /home/test.file fájl információs blokkjaiból kiolvasott információkat. Írjuk ezt az információt egy fájlba:
Outf = open("out",O_CREAT|O_RDWR,0600);
Write(outf, buff, sizeof(buff));
bezár(outf);
szünet;
Kijárat:
bezár(indev);
visszatérés 0;
Ezzel befejeztük az ext2 fájlrendszer logikai szerkezetének vizsgálatát.
Most leírjuk a legnépszerűbb Linux lemezfájlrendszert, az ext2-t. A Linux első kiadása a MINIX 1 fájlrendszert használta, amely rövid fájlnevekkel és 64 MB maximális fájlmérettel rendelkezett. A MINIX 1 fájlrendszert végül felváltotta az első kiterjesztett fájlrendszer, az ext, amely hosszabb fájlneveket és nagyobb fájlméreteket tett lehetővé. Az ext rendszert alacsony hatékonysága miatt (teljesítmény szempontjából) felváltotta a ma is széles körben használt ext2 utódja.
Az ext2-vel rendelkező lemezpartíció az ábrán látható fájlrendszert tartalmazza. 10.17 elrendezés. A 0-s blokkot a Linux rendszer nem használja, és a számítógép indítókódját tartalmazza. A 0. blokkot követően a lemezpartíció blokkcsoportokra van osztva (figyelmen kívül hagyva a lemezhenger határait). Minden csoport a következőképpen van felszerelve.
Az első blokk a szuperblokk, amely információkat tárol a fájlrendszer elrendezéséről, beleértve az i-node-ok számát, a lemezblokkok számát, a szabad lemezblokkok listájának elejét (általában több száz elem). Ezt követi egy csoportleíró, amely információkat tartalmaz a bittérképek helyéről, a csoportban lévő szabad blokkok és i-csomópontok számáról, valamint a csoportban lévő könyvtárak számáról. Ez az információ azért fontos, mert az ext2 fájlrendszer megpróbálja egyenletesen elosztani a könyvtárakat a lemezen.
A két bittérkép nyomon követi a szabad blokkokat és a szabad i-csomópontokat (ez szintén a MINIX 1 fájlrendszertől származik, és megkülönbözteti a legtöbb UNIX fájlrendszertől, amely listát használ a szabad blokkokhoz). Minden bittérkép mérete egy blokk. 1 KB-os blokkmérettel ez a séma 8192 blokkra és 8192 i-csomópontra korlátozza a blokkcsoport méretét. Az első szám valódi határ, a második pedig gyakorlatilag semmi. 4 KB-os blokkokkal a számok négyszer nagyobbak.
Ezután maguk az i-csomópontok találhatók. 1-től maximumig vannak számozva. Minden i-csomópont 128 bájt méretű, és pontosan egy fájlt ír le. Az i-csomópont könyvelési információkat tartalmaz (beleértve mindazt, amit a stat hívás visszaadott, amely egyszerűen átveszi azt az i-node-tól), valamint elegendő információt a fájladatokat tartalmazó lemezblokkok megtalálásához.
Az i-csomópontokat adatblokkok követik. Az összes fájl és könyvtár itt tárolódik. Ha egy fájl vagy könyvtár több blokkból áll, akkor ezeknek a blokkoknak nem kell egymás mellett lenniük a lemezen. Valójában egy nagy fájl blokkjai valószínűleg szétszórva vannak a lemezen.
A könyvtáraknak megfelelő i-csomópontok szétszórva vannak az összes lemezblokk-csoportban. Az Ext2 megpróbálja a normál fájlokat ugyanabba a blokkcsoportba helyezni, mint a szülőkönyvtár, az adatfájlokat pedig ugyanabba a blokkba, mint a forrásfájl i-csomópontja (feltéve, hogy van ott elég hely). Ezt az ötletet a Berkeley Fast fájlrendszerből kölcsönözték. Fájlrendszer(McKusick és munkatársai, 1984). Fogadásra bittérképeket használnak gyors javítások a kiválasztással kapcsolatban
helyek az új fájlrendszeradatok számára.
Új fájlblokkok lefoglalásakor az ext2 néhány (nyolc) további blokkot is előre lefoglal ugyanahhoz a fájlhoz (hogy minimalizálja a fájl töredezettségét a jövőbeni írások miatt). Ez a séma szétosztja a fájlrendszert a lemezen. Jó a teljesítménye is (összefüggő jellegének és csökkentett töredezettségének köszönhetően).
Egy fájl eléréséhez először az egyik Linux rendszerhívást (például open) kell használnia, amelyhez meg kell adnia a fájl elérési útját. Ezt az elérési utat a rendszer elemzi, és az alkotó könyvtárakat kivonja belőle. Ha relatív elérési út van megadva, akkor a keresés a folyamat aktuális könyvtárából indul, ellenkező esetben a gyökérkönyvtárból. Mindenesetre az első könyvtár i-node-ja könnyen megtalálható: a folyamatleíróban van rá mutató, vagy (a gyökérkönyvtár esetében) egy adott blokkban van eltárolva a lemezen.
A könyvtár legfeljebb 255 karakter hosszú fájlneveket tesz lehetővé (10.18. ábra). Minden könyvtár számos lemezblokkból áll (így a könyvtárat atomosan lehet lemezre írni). Egy könyvtárban a fájlok és könyvtárak elemei rendezetlen sorrendben vannak (minden elem közvetlenül követi az előzőt). Az elemek nem léphetik át a blokkhatárokat, ezért általában minden lemezblokk végén van némi fel nem használt bájt.
ábrán látható minden egyes címtárbejegyzés. A 10.18 négy fix hosszúságú mezőből és egy változó hosszúságú mezőből áll. Az első mező az i-node száma, amely 19 a kolosszális fájlnál, 42 a terjedelmes fájlnál és 88 a bigdir könyvtárnál. Ezután jön a rec_len mező, amely a teljes könyvtárbejegyzés méretét adja meg bájtokban (esetleg a név után további kitöltő bájtokkal). Ez a mező a következő bejegyzés megkereséséhez szükséges (abban az esetben, ha a fájlnév ismeretlen számú bájttal van kitöltve). Az ábrán ezt a mezőt nyíl jelzi. Ezután van egy fájl típusú mező, könyvtár stb. Az utolsó rögzített hosszúságú mező a fájlnév hosszát tartalmazza bájtokban (8, 10 és 6 ezt a példát). Végül ott van maga a fájlnév, amelyet egy null bájt zár le, és egy 32 bites határra van kitömve. Ezt további kitöltési bájtok követhetik.
ábrán. A 10.18b ugyanazt a könyvtárat mutatja, miután a voluminous elemet eltávolították. A címtárban mindössze annyit kell tenni, hogy növeljük a rekordméret mezőben a számot. előző fájl kolosszális, és a címtárbejegyzés bájtjait távoli fájl terjedelmes fordulat az első rekord helyőrzőivé. Ezt követően ezek a bájtok használhatók írásra új fájl létrehozásakor.
Mivel a könyvtárak keresése lineárisan történik, sok időbe telhet egy olyan bejegyzés megtalálása, amely egy nagy könyvtár végén található. Ezért a rendszer gyorsítótárat tart fenn a legutóbb elért könyvtárakról. A gyorsítótárban fájlnév alapján keresnek, és ha megtalálják, akkor már nincs szükség a drága lineáris keresésre. Minden egyes elérési út-összetevőhöz bekerül egy dentry objektum a címtárbejegyzés gyorsítótárába, és (az i-csomópontján keresztül) a könyvtárban megkeresi a következő elérési út bejegyzéseket (amíg meg nem találják a fájl tényleges i-csomópontját).
Például egy abszolút elérési út (például /usr/ast/file) által meghatározott fájl megkereséséhez a következő lépéseket kell követni. Először is, a rendszer megkeresi azt a gyökérkönyvtárat, amelyet a 2-es számú i-node általában használ (különösen, ha az 1-es számú i-node hibás blokkok számára van fenntartva). A megfelelő bejegyzést a címtárbejegyzés gyorsítótárába helyezi (a gyökérkönyvtár jövőbeli kereséseihez). Ezután megkeresi a gyökérkönyvtárban az "usr" karakterláncot, hogy megkapja a /usr könyvtár i-node számát (amely szintén bekerül a könyvtár elem-gyorsítótárába). Ezt az i-csomópontot ezután beolvassa, és lemezblokkokat bont ki belőle, így a /usr könyvtár olvasható és kereshető az "ast" karakterlánc után. Miután megtalálta a megfelelő bejegyzést, az /usr/ast könyvtár i-node száma meghatározható belőle. Ha ezt az i-node számot kapja, akkor ez olvasható és könyvtárblokkok találhatók. Végül megkeressük a "file" szót, és megtaláljuk az i-node számát. Így a relatív elérési út használata nemcsak kényelmesebb a felhasználó számára, hanem csökkenti a rendszer munkáját is.
Ha a fájl jelen van, a rendszer lekéri az i-node számát, és az i-node tábla indexeként használja (a lemezen), hogy megkeresse a megfelelő i-node-ot, és beolvassa a memóriába. Ez az i-csomópont az i-node táblában van elhelyezve, egy kernel adatszerkezetben, amely tartalmazza az összes i-csomópontot a megnyitáshoz Ebben a pillanatban fájlok és könyvtárak. Az i-node elemformátumnak tartalmaznia kell (legalább) a stat rendszerhívás által visszaadott összes mezőt, hogy a stat hívás működjön (lásd: 10.10. táblázat). táblázatban. A 10-13. ábra a Linux fájlrendszer által támogatott i-node szerkezet néhány mezőjét mutatja be. A tényleges i-node szerkezet sokkal több mezőt tartalmaz, mivel ugyanazt a struktúrát használják a könyvtárak, eszközök és egyéb speciális fájlok megjelenítésére. Az i-node struktúra jövőbeli használatra fenntartott mezőket is tartalmaz. A történelem azt mutatja, hogy a fel nem használt bitek nem maradnak sokáig tétlenül.
Most nézzük meg, hogyan olvassa be a rendszer a fájlt. Ne feledje, hogy egy tipikus könyvtári eljáráshívás az olvasási rendszerhívás futtatására így néz ki:
n = read(fd, puffer, nbyte);
Amikor a kernel átveszi az irányítást, csak ezzel a három paraméterrel és a belső tábláiban található információkkal tud kezdeni (a felhasználóra vonatkozóan). E belső táblák egyik eleme a fájlleírók tömbje. Fájlleírók indexelik, és megnyitott fájlonként egy elemet tartalmaz (legfeljebb bizonyos számú, alapértelmezés szerint általában 32-ig).
Az ötlet az, hogy ezzel a fájlleíróval kezdjük, és a megfelelő bnode-dal fejezzük be. Nézzünk meg egy lehetséges sémát: tegyünk egy mutatót egy csomópontra a fájlleírók táblázatában. Az egyszerűség ellenére ez a módszer(sajnos) nem működik. A probléma ez. Minden fájlleírónak rendelkeznie kell egy társított fájlmutatóval, amely meghatározza azt a bájtot a fájlban, ahol a következő olvasási vagy írási művelet kezdődik. Hol kell ezt a mutatót tárolni? Az egyik lehetőség az, hogy a csomóponttáblázatba helyezi. Ez a megközelítés azonban nem működik, ha több, egymástól független folyamat egyszerre nyitja meg ugyanazt a fájlt, mivel minden folyamatnak saját mutatóval kell rendelkeznie.
A második megoldás egy mutató elhelyezése a fájlleíró táblában. Minden fájlt megnyitó folyamatnak megvan a maga pozíciója a fájlban. Sajnos ez a séma sem működik, de a kudarc oka igen ez az eset nem annyira nyilvánvaló és a természettel kapcsolatos megosztás fájlokat Linux rendszeren. Tekintsük az 5. shell scriptet, amely két parancsból (p1 és p2) áll, amelyeket egymás után kell végrehajtani. Ha a parancsfájlt a parancssorból hívják meg
akkor p1 várhatóan az x fájlba írja a kimenetét, majd a p2 szintén az x fájlba írja, ahol a p1 abbamaradt.
Amikor a shell elindítja a p1-et, az x fájl eleinte üres lesz, így a p1 egyszerűen elkezd írni a fájlba a 0 pozícióban. Amikor azonban a p1 kész, szükség van valamilyen mechanizmusra annak biztosítására, hogy a p2 a kezdőpozíciót ne 0-t lássa (hanem pontosan ez történik, ha a fájl pozíciója a fájlleíró táblában van tárolva), de az az érték, amelynél a pi megállt.
Ennek módja az ábrán látható. 10.19. A trükk egy új tábla bevezetése – a leírás táblázat nyissa meg a fájlokat(fájlleíró tábla megnyitása) - a fájlleíró tábla és az i-node tábla közé, és abban tárolja a fájlmutatót (valamint az olvasási/írási bitet). Az ábrán a szülő folyamat a shell, a gyermek pedig először a pi folyamat, majd a p2 folyamat. Amikor a shell létrehozza a pi folyamatot, annak felhasználói szerkezete (beleértve a fájlleíró táblát is) ugyanannak a shell-struktúrának a pontos másolata, tehát mindkettő ugyanarra a nyitott fájlleíró táblára mutat mutatókat. Amikor a pi folyamat kilép, a shell fájlleírója továbbra is a megnyitott fájlleíró táblázatra mutat, amely tartalmazza a p1 folyamat pozícióját a fájlban. Amikor a shell most létrehozza a p2 folyamatot, az új gyermekfolyamat automatikusan örökli a fájlban lévő pozíciót, anélkül új folyamat, és a shellnek sem szükséges tudnia az adott pozíció aktuális értékét.
Ha valamilyen idegen folyamat megnyitja a fájlt, akkor a megnyitott fájlleíró táblában saját bejegyzést kap a fájlban elfoglalt pozíciójával, amire pontosan szükség van. Így a megnyitott fájlleíró tábla célja, hogy a szülő- és utódfolyamatok egyetlen mutatót oszthassanak meg egy fájlban, de az idegen folyamatokhoz személyes mutatókat rendeljenek.
Tehát (visszatérve az olvasás végrehajtásának problémájához) megmutattuk, hogyan határozzák meg a fájl pozícióját és az i-node-ot. Az I-csomópont tartalmazza a fájl első 12 blokkjának lemezcímét. Ha a fájl pozíciója az első 12 blokkba esik, akkor olvassa el kívánt blokk a fájl és az adatok a felhasználóhoz másolódnak. A 12 blokknál hosszabb fájlok esetén az i-node egyetlen indirekt blokk lemezcímét tartalmazza (10.19. ábra). Ez a blokk további lemezblokkok lemezcímeit tartalmazza. Például, ha a blokk mérete 1 KB és a lemezcím 4 bájt, akkor egyetlen közvetett blokk legfeljebb 256 lemezcímet tárolhat. Ez a séma legfeljebb 268 KB méretű fájlok támogatását teszi lehetővé.
ext2(más néven ext2fs) - Második kiterjesztett fájlrendszer(Second Extended File System) egy Linux kernelre épülő fájlrendszer. Az ext2 megalkotója és fejlesztője a Remy Card. Az ext2 fájlrendszert ő építette fel a régi, korábbi verzió - ext.
Az olyan mutatók tekintetében, mint a sebesség és a teljesítmény, ez a fájlrendszer viszonyítási alapként szolgálhat. Ezt bizonyítják a fájlrendszer-teljesítménytesztek eredményei. Például a Dell Tech Center szekvenciális olvasási/írási sebességtesztjeiben az ext2 jobban teljesít, mint az ext3, és csak olvasási sebességben múlja felül a modernebb ext4-et.
Az ext2 fő hátránya, hogy nem naplózó fájlrendszer. Ezt a hiányosságot azonban a következő fájlrendszer - ext3 - megszüntette.
Az ext2 flash kártyákon és szilárdtestalapú meghajtókon (SSD) használatos, mivel a naplózás hiánya előnyt jelent, ha írási cikluskorlátokkal rendelkező meghajtókkal dolgozik.
A Linux rendszer rohamos fejlődése idején a Minix OS fájlrendszert használta. Elég stabil volt, de 16 bites. Ennek eredményeként partíciónként 64 Mb-os szigorú korlátja volt. Ezenkívül korlátozták a fájlnév maximális hosszát, amely 14 karakter volt.
Ezek a korlátok együttesen indokolták a "bővített fájlrendszer" kifejlesztését (innen a " Bővített fájlrendszer »). Azt a feladatot kapta, hogy oldja meg Minix két kulcsfontosságú problémáját. Az új fájlrendszert 1992 áprilisában hozták nyilvánosságra. Ez volt az Ext, amely a fájl méretkorlátját 2 gigabájtra terjesztette ki, a fájlnév-korlátot pedig 255 karakterre állította.
Az új fájlrendszer sikere ellenére azonban még mindig maradt jó néhány megoldatlan probléma. Például nem támogatták a külön hozzáférést, nem voltak időbélyegek az adatok módosításához. Ezeknek a problémáknak a megoldása volt az indítéka a kiterjesztett ext2 fájlrendszer következő verziójának (" Második kiterjesztett fájlrendszer). Az ext2-t 1993 januárjában fejlesztették ki, és POSIX-kompatibilis ACL-eket és kiterjesztett fájlattribútumokat is megvalósított.
Az ext2 címtárhierarchia gráf hálózatként jelenik meg. Ez annak köszönhető, hogy egy fájl egyszerre több könyvtárba is bekerülhet.
Minden fájltípusnak szimbolikus neve van. A hierarchikusan szervezett fájlrendszerekben általában háromféle nevet használnak: egyszerű, összetett és relatív. Ugyanez az ext2-vel. Egyszerű név esetén a korlátozás az, hogy hossza ne haladja meg a 255 karaktert, emellett a név ne tartalmazzon NULL karaktert és perjelet.
Ami a NULL karaktert illeti, a korlátok a karakterláncok C nyelvi megjelenítéséhez kapcsolódnak, a perjel karakter esetében minden abban rejlik, hogy elválasztó karakterként használják a könyvtárak között.
A teljesen minősített név az összes könyvtár egyszerű szimbolikus neveinek lánca, amelyen keresztül az elérési út a gyökértől a adott fájl. Az ext2-ben egy fájl több könyvtárban is lehet, ami azt jelenti, hogy több teljes neve is lehet (egy fájl, több teljes név). De egyébként is a teljes név határozza meg a fájlt.
ext2 attribútumok:
A fájlattribútumok speciális táblákban tárolódnak, nem könyvtárakban, ahogy az egyszerű fájlrendszerekben megszokott. Ennek eredményeként a katalógusnak nagyon egyszerű szerkezet, amely két részből áll: egy inode számból és egy névből.
Lemezpartíció szerkezete
Az ext2 részeként a következők különböztethetők meg:
A teljes lemezpartíció fix méretű blokkokra van osztva, amelyek a szektorméret többszörösei (1024, 2048, 4096 vagy 8192 bájt). A blokk mérete a lemezpartíción lévő fájlrendszer létrehozásakor kerül megadásra. Minden blokk sorozatszámot kap. A töredezettség és a merevlemezfej-mozgások számának csökkentése érdekében nagy mennyiségű adat olvasásakor a blokkokat csoportokba egyesítik.
A fájlrendszer alapkoncepciója az inode (más néven inode - információs csomópont). Ez egy speciális struktúra, amely információkat tartalmaz a fájl tulajdonságairól és fizikai helyéről. Az index-dekódolókat egy táblázatba egyesítik, amely az egyes blokkcsoportok elején található. A szuperblokk az ext2 fájlrendszer fő eleme. Általános információkat tartalmaz a fájlrendszerről. A szuperblokk 1024 bájtra található a szakasz elejétől számítva. A szuperblokk integritása határozza meg a fájlrendszer állapotát. Az operációs rendszer több biztonsági másolatot készít a szuperblokkról - arra az esetre, ha a partíció megsérül. A szuperblokk után következő blokk egy globális leíró táblát tartalmaz - a blokkcsoportok leírása tömb formájában, általános információkkal az összes blokkcsoportról.
Csoport blokkolása
Az ext2 partíción lévő összes blokk csoportokra van osztva. Minden csoporthoz külön bejegyzés jön létre a globális leíró táblában. Ez a bejegyzés az alapvető paramétereket tárolja, mint például: a blokkszám bittérképekben és táblázatokban, a szabad blokkok száma a csoportban, a könyvtárakat tartalmazó inode-ok száma.
Bittérkép blokkolása egy olyan rendszer, amelyben minden bit tájékoztat arról, hogy a neki megfelelő blokk hozzá van-e rendelve valamelyik fájlhoz. Ha a bit 1, akkor a blokk foglalt. Az inode bitmap hasonló funkciót lát el: megmutatja, hogy mely inódok foglaltak és melyek nem. Linux kernel megpróbálja egyenletesen elosztani a könyvtári inódákat a csoportok között, és áthelyezi a fájlinódákat a szülőkönyvtárral rendelkező csoportba. Az összes fennmaradó terület, amely a táblázatban adatként jelenik meg, a fájlok tárolására van lefoglalva.
Adatcímző rendszer
Az adatcímző rendszer a fájlrendszer egyik legkomolyabb és legfontosabb összetevője. Ennek köszönhetően a kívánt fájl a lemezen található sok üres vagy foglalt blokk között található.
Az ext2 a következő fájlblokk-címzési sémát használja. A fájl címének tárolásához 15 mező van lefoglalva, amelyek mindegyike 4 bájtból áll. Ha a fájl 12 blokkba illeszkedik, akkor a megfelelő klaszterek számai a cím első tizenkét mezőjében szerepelnek. Ha a fájl mérete meghaladja a 12 blokkot, akkor a következő mező annak a klaszternek a címét tartalmazza, amelyben a fájl következő blokkjainak száma található. Így a tizenharmadik mezőt indirekt címzésre használjuk.
A 4096 bájt maximális blokkméret mellett a 13. mezőnek megfelelő fürt legfeljebb 1024 következő blokkszámot tartalmazhat a fájlban. Ha a fájl mérete meghaladja a 12+1024 blokkot, akkor a 14. mező kerül felhasználásra, amely egy 1024 fürtszámot tartalmazó fürt címét tartalmazza, amelyek mindegyike a fájl 1024 blokkjára vonatkozik. Itt kettős indirekt címzést használnak. És ha a fájl több mint 12 + 1024 + 1048576 blokkot tartalmaz, akkor az utolsó 15. mező a hármas közvetett címzésre szolgál.
Egy ilyen címzési rendszer 4096 bájt maximális blokkméret mellett lehetővé teszi a 2 TB-nál nagyobb fájlok használatát.
Fájlrendszer(angol fájlrendszer) - parancs, amely meghatározza az adatok rendszerezési, tárolási és elnevezési módját az informatikai berendezések információhordozóin (hordozható flash memóriakártyák használatával elektronikus eszközök: digitális kamerák, mobiltelefonok stb. e) és számítástechnika. Meghatározza az általában fájlok formájában csoportosított információk tartalmának és fizikai tárolásának formátumát. Egy adott fájlrendszer határozza meg a fájl (mappa) nevének méretét, a maximális lehetséges fájl- és partícióméretet, valamint a fájlattribútumok készletét. Egyes fájlrendszerek biztosítják szolgáltatási képességek mint például a hozzáférés-vezérlés vagy a fájltitkosítás.
Fájlrendszeri feladatok
Bármely fájlrendszer fő funkciói a következő feladatok megoldására irányulnak:
fájl elnevezése;
az alkalmazások fájljaival való munka programfelülete;
a fájlrendszer logikai modelljének hozzárendelése az adattárház fizikai szervezetéhez;
a fájlrendszer stabilitásának megszervezése áramkimaradások, hardver- és szoftverhibák ellen;
A többfelhasználós rendszerekben egy másik feladat jelenik meg: az egyik felhasználó fájljainak védelme egy másik felhasználó illetéktelen hozzáférésétől, valamint közös munka fájlokkal, például amikor az egyik felhasználó megnyit egy fájlt, mások számára ugyanaz a fájl átmenetileg csak olvasható módban lesz elérhető.
A fájlrendszer a számítógép által a merevlemezen lévő információk rendszerezésére használt fő struktúra. Új merevlemez telepítésekor azt particionálni és egy adott fájlrendszerhez kell formázni, ami után adatokat és programokat tud tárolni. A Windowsnak három van lehetséges opciók fájlrendszer: NTFS, FAT32 és a ritkán használt régi FAT rendszer (más néven FAT16).
Az NTFS az előnyben részesített fájlrendszer a Windows ezen verziójához. Számos előnnyel rendelkezik a korábbi FAT32 rendszerhez képest; ezek közül néhányat az alábbiakban sorolunk fel.
Bizonyos lemezhibák utáni automatikus helyreállítás képessége (a FAT32 nem rendelkezik ezzel a képességgel).
Továbbfejlesztett támogatás a nagy merevlemezekhez.
Magasabb fokú biztonság. Engedélyekkel és titkosítással megakadályozhatja, hogy a felhasználók hozzáférjenek bizonyos fájlokhoz.
Korábban a FAT32 fájlrendszert és a ritkán használt FAT rendszert használták Windows verziók, beleértve a Windows 95-öt, a Windows 98-at és a Windows Millennium Editiont. A FAT32 fájlrendszer nem biztosítja az NTFS által biztosított biztonsági szintet, így ha egy számítógép FAT32 formátumú partícióval vagy kötettel rendelkezik, a partíción lévő fájlok bárki számára láthatók, aki hozzáfér a számítógéphez. A FAT32 fájlrendszernek is vannak fájlméret-korlátai. A Windows ezen verziójában nem lehet 32 GB-nál nagyobb FAT32-partíciót létrehozni. Ezenkívül a FAT32 partíció nem tartalmazhat 4 GB-nál nagyobb fájlt.
A FAT32 rendszer használatának fő oka az lenne, hogy a számítógép képes lesz a Windows 95, Windows 98 vagy Windows Millennium Edition, valamint a Windows ezen verziójának futtatására (több operációs rendszer konfigurációja). Egy ilyen konfiguráció létrehozásához telepítenie kell az operációs rendszer egy korábbi verzióját egy FAT32-vel vagy FAT-tal formázott partícióra, így ez lesz az elsődleges (az elsődleges partíció tartalmazhatja az operációs rendszert). Más szakaszok innen érhetők el előző verziók A Windows rendszert is FAT32-re kell formázni. Több korai változatai A Windows csak az NTFS hálózati partíciókhoz vagy kötetekhez tud hozzáférni. Az NTFS-partíciók a helyi számítógépen nem lesznek elérhetők.
ZSÍR - pluszok:
Kevés szükséges ahhoz, hogy hatékony legyen véletlen hozzáférésű memória.
Gyors munka kis és közepes könyvtárakkal.
A lemez átlagosan kevesebb fejmozgást végez (az NTFS-hez képest).
Hatékony munka lassú lemezeken.
ZSÍR – hátrányok:
Katasztrofális teljesítményvesztés a növekvő töredezettség miatt, különösen nagy meghajtók esetén (csak FAT32 esetén).
Nehézségek a nagy (mondjuk a lemezméret legalább 10%-a) fájlokhoz való véletlenszerű hozzáférés során.
Nagyon lassú munka tartalmazó könyvtárakkal nagyszámú fájlokat.
NTFS előnyei:
A fájlok töredezettsége alig vagy egyáltalán nincs hatással magára a fájlrendszerre – a töredezett rendszer teljesítménye csak a fájladatokhoz való hozzáférés tekintetében romlik.
A könyvtárszerkezet összetettsége és az egy könyvtárban található fájlok száma sem jelent különösebb akadályt a teljesítménynek.
Gyors hozzáférés egy fájl tetszőleges töredékéhez (például nagy .wav fájlok szerkesztése).
Nagyon gyors hozzáférés kis fájlokhoz (néhány száz bájt) - a teljes fájl ugyanazon a helyen van, ahol a rendszeradatok (MFT rekord).
NTFS hátrányai:
Jelentős rendszermemóriaigény (64 MB az abszolút minimum, több jobb).
A Bus Mastering nélküli lassú lemezek és vezérlők nagymértékben lelassítják az NTFS teljesítményét.
A közepes méretű könyvtárakkal nehéz dolgozni, mert szinte mindig töredezettek.
A hosszú ideje 80–90%-os telítettségben futó lemez rendkívül alacsony teljesítményt mutat.
A következő fájlrendszerek tekinthetők "natív" Linuxnak (vagyis azok, amelyekre telepíthető, és amelyekről el tud indulni): ext2fs, ext3fs, ext4fs, ReiserFS, XFS, JFS.Általában nekik kínálják fel a választást a disztribúciók túlnyomó többségének telepítésekor. Természetesen vannak módok Linux telepítések FAT/VFAT/FAT32 fájlrendszerekre, de ez csak azoknak a mézeseknek és uraknak szól, akik sokat értenek a perverziókhoz, és nem is beszélek róluk.
A fájlrendszer kiválasztásának fő kritériuma általában a megbízhatóság és a sebesség. Egyes esetekben a kompatibilitási tényezőt is figyelembe kell venni - ez ebben az esetben azt jelenti, hogy más operációs rendszerek képesek hozzáférni egy adott fájlrendszerhez.
Kezdem a ReiserFS-sel – mert a jegyzet megírásának oka a kérdés volt: mit tekintsünk kis fájloknak? Hiszen köztudott, hogy a kis fájlokkal való munka hatékonysága az erőssége ennek a fájlrendszernek.
Tehát a kis fájlok kisebb fájlok, mint a fájlrendszer logikai blokkja, amely Linuxban a legtöbb esetben négy kilobájtnak felel meg, bár a formázás során bizonyos határokon belül beállítható (az adott FS-től függően). Számtalan ilyen kis fájl található bármely Unix-szerű operációs rendszerben. Tipikus példa erre a FreeBSD portok, Gentoo portok és hasonló portolt rendszerek fáját alkotó fájlok.
A legtöbb fájlrendszerben az ilyen mini fájloknak saját inode (a fájl metainformációit tartalmazó információs csomópont) és egy adatblokk is van, ami lemezterület-felhasználáshoz és lassabb fájlműveletekhez vezet. Különösen ez az oka a FreeBSD fájlrendszer (mind a régi, UFS, mind az új, UFS2) katasztrofális átgondoltságának, amikor a saját portrendszerével dolgozik.
A ReiserFS fájlrendszerben ilyen esetekben nem osztanak ki külön adatblokkokat - sikerül a fájladatokat közvetlenül a saját inode területére tolni. Ennek köszönhetően és lemez terület mentésre kerül, és a teljesítmény növekszik - szó szerint többszörösére az összes többi FS-hez képest.
A kis ReiserFS fájlok ilyen kezelése egy legendát adott a megbízhatatlanságáról. Valójában a fájlrendszer összeomlásakor (vagyis a szolgáltatási területek megsemmisülésekor) az inode-okkal együtt elhelyezett adatok is eltűnnek velük együtt - és visszahozhatatlanul. Míg azokban a fájlrendszerekben, ahol az inódok és az adatblokkok térben mindig el vannak választva, az utóbbiak elméletileg visszaállíthatók. Tehát az ext2/ext3 esetében még olyan eszközök is vannak, amelyek lehetővé teszik ezt.
Azonban, mint minden legenda, ez is csak a hitelesség benyomását kelti. Először is, az állandó adatvesztés csak nagyon kisméretű fájlokra vonatkozik. A felhasználóik között gyakorlatilag nincs ilyen, és az összes többi könnyen visszaállítható az elosztókészletből.
Másodszor, amikor az adatok helyreállításának lehetőségéről beszélünk olyan blokkokból, amelyek elvesztették kötődésüket az inode-jukhoz, nem véletlenül használtam az „elméleti” szót. Mert a gyakorlatban ez a foglalkozás rendkívül időigényes, nem ad garantált eredményt. Mindenki, akinek ezt kellett tennie, egyetért azzal, hogy csak a teljes reménytelenségből lehet beletörődni. És ez minden Linux fájlrendszerre vonatkozik. Ez a szempont tehát elhanyagolható a fájlrendszer kiválasztásakor.
Az általános teljesítményt tekintve a ReiserFS határozottan gyorsabb, mint az összes többi naplózott FS, és bizonyos tekintetben még az ext2-t is felülmúlja. Néhány elterjedt fájlfájl-művelet sebességének összehasonlításának eredményeit itt találja.
De a ReiserFS kompatibilitásával a helyzet valamivel rosszabb. Hozzáférés az operációs rendszerből Windows családok, amennyire én tudom, nem lehetséges. A BSD család néhány operációs rendszere (DragonFlyBSD, FreeBSD) támogatja ezt a fájlrendszert, de csak olvasható módban. Még annak a valószínűsége sem nulla, hogy egy tetszőleges múltkori Linux LiveCD nem támogatja a ReiserFS-t.
És itt az ideje, hogy emlékezzünk az ext3fs-re. Előnye egyáltalán nem a nagyobb megbízhatóságban rejlik – ez ugyanaz a legenda, mint a ReiserFS instabilitása. Annyit hallottam az ext3fs összeomlásáról, mint a ReiserFS összeomlásáról. Jómagam sem az egyiket, sem a másikat nem tudtam elpusztítani. Hacsak nem működött az ext2-vel – de még az is nagyon régen volt, a 2.2-es (vagy akár a 2.0-s) kernel idején.
Nem, az ext3fs fő előnye a kompatibilitása – garantáltan elolvassa bármely Linux rendszer. Például, amikor egy ősi LiveCD asszisztensből helyreállítottam - egy olyan helyzet, ami szinte nem is olyan hihetetlen, bele kellett mennem. Ismétlem, a legtöbb BSD-rendszer könnyen megérti az ext3fs-t (bár naplózás nélkül). A Windowshoz is, ha jól tudom, mindenféle illesztőprogram és beépülő modul létezik fájlkezelők(típus Total Commander), amelyek hozzáférést biztosítanak az ext2fs/ext3fs partíciókhoz.
A teljesítmény tekintetében az ext3fs vegyes benyomást kelt. Először is, teljesítménye nagymértékben függ a naplózási módtól, amelyből három van: teljes adatnaplózással, részleges adatnaplózással és csak metaadatok naplózásával. Mindegyik módban eltérő teljesítményt mutat a különböző típusú fájlműveleteknél. A teljesítmény azonban mindenesetre nem rekord.
Ha azonban a gyorsaság követelményét helyezik előtérbe, akkor az ext2fs itt versenyen kívül esik - azonban ebben az esetben egyáltalán el kell viselni a naplózás hiányát. Következésképpen a hosszadalmas fájlrendszer-ellenőrzések bármilyen helytelen leállás esetén - és a modern lemezek mennyisége mellett ez hosszú ideig elhúzódhat ...
Az XFS-sel kapcsolatban a következőket lehet elmondani. Ami a kompatibilitást illeti, minden vonatkozik rá, ami ReiserFS-re íródott – ráadásul egy ideig nem támogatta a szabványos Linux kernel. Teljesítmény szempontjából az XFS sem tündököl, összességében nagyjából az ext3fs szintjén beszél. A fájlok törlésének működése pedig általában lehangoló lassúságot mutat.
Tapasztalataim szerint az XFS használata kifizetődő, ha nem csak nagy, hanem nagyon nagy fájlokkal dolgozik – amelyek valójában csak DVD-képek és videofájlok.
Visszatérek a megbízhatóság kérdésére. A banális kikapcsolás a normál felhasználói munka során általában fájdalommentesen továbbítja az összes naplózott fájlrendszert (és egyik sem biztosítja a lemezre nem írt felhasználói műveletek biztonságát - megmenti a fuldoklókat, és itt marad a fuldoklók munkája). Igaz, bármely fájlrendszer esetében szimulálható egy olyan helyzet, amelyben a tápellátás kikapcsolása többé-kevésbé súlyos károsodáshoz vezet. A való életben azonban nem valószínű, hogy ilyen helyzetek előfordulnak. És teljesen kiküszöbölheti őket egy forrás megszerzésével szünetmentes tápegység- jobban bízik az adatok biztonságában, mint a fájlrendszer típusa. Nos, mindenesetre csak a rendszeres biztonsági mentésük lehet garancia a megsemmisült adatok helyreállítására ...
Úgy gondolom, hogy a fenti információk elegendőek a megalapozott választáshoz. Személyes döntésem az elmúlt néhány évben a ReiserFS volt. Alkalmanként olyan rendszereken, ahol indokolt mindent áthelyezni a root partíción kívülre, ami csak lehetséges, célszerű az ext3fs a root fájlrendszerhez, és a ReiserFS minden máshoz.
Ha külön partíció van biztosítva a /boot könyvtárhoz (és ez a használat során javasolt GRUB rendszerbetöltő fejlesztői) - számára az ext2fs kivételével semmilyen más fájlrendszer nem indokolt, itt semmiféle naplózásnak nincs értelme. Végül, ha külön partíciót hozunk létre mindenféle multimédiás anyag számára, akkor gondolhatunk az XFS-re.
Ha módszeresebben közelítjük meg a magyarázatot
ext - be kezdeti szakaszban A Linux fejlesztésben az ext2 rendszer (bővített fájlrendszer, 2-es verzió) dominált. 2002 óta felváltotta az ext3 rendszer, amely nagyrészt kompatibilis az ext2-vel, de támogatja a naplózási funkciókat is, illetve ha a kernel 2.6-os és újabb verziójával dolgozunk, akkor az ACL-t is. A maximális fájlméret 2 TB, a fájlrendszer maximális mérete 8 TB. 2008 végén hivatalosan is bejelentették az ext4 verzióját, amely visszafelé kompatibilis az ext3-mal, de számos funkciót a korábbiaknál hatékonyabban implementálnak. Ráadásul a fájlrendszer maximális mérete 1 EB (1 048 576 TB), és számíthatunk rá, hogy ez egy ideig elég lesz. A reiserről – A rendszert alapítójáról, Hans Reiserről nevezték el, és ez volt az első olyan rendszer, amely naplózási funkcióval rendelkezik, amely elérte a Linux kernelt adatokért. A zp SUSE verziója még szabványnak számított egy ideig. A reiser fő előnye az ext3-mal szemben a nagyobb sebesség és a jobb elhelyezés, amikor kis fájlokkal dolgozik (és a legtöbb fájl a fájlrendszerben általában kicsi). Idővel azonban a reiseferek fejlesztése leállt. A 4-es verziót már nagyon régen bejelentették, ami még mindig nincs készen, és a 3-as verzió támogatása megszűnt. Az xfs-ről – Az xfs fájlrendszert eredetileg IRIX operációs rendszeren futó SGI munkaállomásokhoz fejlesztették ki. Az Xfs különösen jó nagy fájlokkal való munkavégzéshez, különösen ideális streaming videókhoz. A rendszer támogatja a kvótákat és a kiterjesztett attribútumokat (ACL).
jfs
jfs – az a66peBHaTypaJFS a „Journaled File System” rövidítése. Eredetileg az IBM számára fejlesztették ki, majd Linuxra adaptálták. A Jfs soha nem örvendett igazán nagy elismerésnek a Linuxban, és jelenleg nyomorúságos, más fájlrendszereknél gyengébb életet él.
brtfs
brtfs – ha ez a vezető kernelfejlesztők akarata, a Linux brtfs fájlrendszere fényes jövő előtt áll. Ezt a rendszert az Oracle az alapoktól kezdve fejlesztette ki. Tartalmazza az eszközleképezőt és a RAID támogatást. A Brtfs leginkább a Sun ZFS-ére hasonlít. Legérdekesebb funkciói közé tartozik a fájlrendszer menet közbeni ellenőrzése, valamint az SSD támogatása (a szilárdtest-meghajtók flash memórián alapuló merevlemezek). Sajnos a brtfs-en végzett munka belátható időn belül nem fejeződik be. A Fedora 11-es verziója óta lehetséges a brtfs telepítése, de csak fájlrendszer-fejlesztőknek ajánlom a használatát!
Nincs „leggyorsabb” vagy „legjobb” fájlrendszer – a becslés attól függ, hogy mire kívánja használni a rendszert. Kezdők Linux felhasználók dolgozni vele helyi számítógép, az ext3-mal, a szerveradminisztrátoroknak pedig az ext4-gyel javasolt dolgozni. Természetesen az ext4 gyorsabb, mint az ext3, de az ext4 adatmegbízhatósága lényegesen rosszabb – könnyen elveszhet az információ, ha a rendszer hirtelen leáll.
Ha egy második UNIX-szerű operációs rendszert telepített a számítógépére, akkor az alábbi fájlrendszerek jól jönnek az adatcseréhez (egyik operációs rendszerről a másikra).
sysv - SCO, Xenix és Coherent OS használja.
ufs - A FreeBSD, a NetBSD, a NextStep és a SunOS használja. A Linux csak az ilyen fájlrendszerekből tud információkat olvasni, de nem tudja módosítani az adatokat. A BSD szegmensek eléréséhez szükség lesz a BSD lemezcímke kiterjesztésre. Hasonló kiterjesztés létezik a SunOS partíciós táblákhoz.
A ZFS relatív új rendszer, amelyet a Sun fejlesztett ki a Solaris számára. Mivel a ZFS kód nem felel meg a GPL licencnek, nem integrálható a Linux kernellel. Emiatt a Linux ezt a fájlrendszert csak közvetetten, a FUSE-n keresztül támogatja.
Windows, Mac OS X
A következő fájlrendszerek hasznosak lehetnek az MS DOS, Windows, OS/2 és Macintosh rendszerekkel történő információcserénél.
vfat – a Windows 9x/ME rendszerben használatos. A Linux képes információkat olvasni az ilyen partíciókról, és módosítani tudja azokat. A vfat rendszer-illesztőprogramok lehetővé teszik a régi MS DOS fájlrendszerekkel való munkát (8 + 3 karakter).
ntfs - a rendszert a Windows minden modern verziójában használják: otNT és újabb. A Linux képes olvasni és módosítani a fájljait.
A hfs és a hfsplus az Apple számítógépek által használt fájlrendszerek. A Linux képes olvasni és módosítani a fájljait.
Az adat-CD-k és DVD-k általában saját fájlrendszert használnak.
iso9660 – A CD-ROM-ok fájlrendszerét az ISO-9660 szabvány írja le, amely csak rövid fájlneveket engedélyez. A hosszú neveket a különböző operációs rendszerek különböző módon támogatják, sokféle, egymással nem kompatibilis kiterjesztés segítségével. Linux rendszer képes együttműködni a UNIX-ban megszokott Rockridge bővítménnyel és a Microsoft által kifejlesztett Joliet bővítménnyel.
udf - ez a formátum (univerzális lemezformátum) az ISO 9660 örököseként jelent meg és fejlődött ki.
Hálózati fájlrendszerek
A fájlrendszereknek nem kell bekapcsolva lenniük helyi lemez- Ők
csatlakozhat a számítógéphez és a hálózaton keresztül. A Linux kernel különféle hálózati fájlrendszereket támogat, amelyek közül a következők a leggyakrabban használtak.
smbfs/cifs – segítség a hálózathoz való csatlakozáshoz Windows könyvtárak vagy a Sambát egy könyvtárfába.
Az nfs a UNIX legfontosabb hálózati fájlrendszere.
coda - ez a rendszer nagyon hasonlít az NFS-hez. Sok van benne további jellemzők de nem túl gyakori.
ncpfs – a Novell Netware által használt NetWare kernel protokollon fut;oH.
Virtuális fájlrendszerek
A Linuxban számos olyan fájlrendszer létezik, amelyek nem merevlemezen (vagy más adathordozón) való adatok tárolására szolgálnak, hanem csak a kernel és a felhasználói programok közötti információcserére.
devpts – Ez a fájlrendszer hozzáférést biztosít pszeudoterminálokhoz (röviden PTY) a /dev/pts/* fájlon keresztül, a UNIX-98 specifikációnak megfelelően. (A pszeudoterminálok soros interfészt emulálnak. UNIX/Linux rendszereken ezeket az interfészeket terminálemulátorok, például xterm használják. Általában olyan eszközöket használnak, mint a /dev/ttypn. Ezzel szemben a UNIX-98 specifikáció új eszközöket határoz meg. További részletek az információ a H0WT0 szöveges terminálon jelenik meg.)
proc és sysfs - a proc fájlrendszer a kernel és a folyamatok kezelésével kapcsolatos szolgáltatási információk megjelenítésére szolgál. Ezen kívül a sysfs fájlrendszer kapcsolatokat épít ki a kernel és a hardver között. Mindkét fájlrendszer a /proc és a /sys helyekre van csatlakoztatva.
tmpfs – Ez a rendszer a System V szerinti megosztott memórián alapul. Általában a /dev/shm pozícióban csatlakozik, és hatékony információcserét biztosít két program között. Egyes disztribúciókon (pl. Ubuntu) a /var/run és /var/lock könyvtárak is a tmpfs fájlrendszer segítségével jönnek létre. Az ezekben a könyvtárakban található fájlokat egyes hálózati démonok folyamatazonosító számok és fájlhozzáférési információk tárolására használják. A tmpfs-nek köszönhetően ezek az adatok most megjelennek a RAM-ban. A módszer garantálja a nagy sebességet, valamint azt, hogy a számítógép leállítása után a /var/run vagy a /var/lock könyvtárban nem maradnak fájlok.
usbfs - az usbfs fájlrendszer a kernel 2.6-os és újabb verzióitól kezdve információkat ad a csatlakoztatott USB-eszközökről. Általában a proc fájlrendszerbe integrálva van. Az USB-eszközök támogatásáról Linux alatt.
Egyéb fájlrendszerek
auto - valójában nincs ilyen nevű fájlrendszer. Az auto szó azonban használható az /etc/fstab fájlban vagy a mount paranccsal a fájlrendszer megadására. Ebben az esetben a Linux megpróbálja önállóan felismerni a fájlrendszert. Ez a módszer a legtöbb nagyobb fájlrendszerrel működik.
autofs, autofs4
Az autofs, autofs4 szintén nem fájlrendszerek, hanem olyan kernelkiterjesztések, amelyek automatikusan végrehajtják a mount parancsot a kiválasztott fájlrendszerekhez. Ha egy fájlrendszert egy ideig nem használtak, akkor a rendszer automatikusan végrehajtja az umount parancsot. Ez a módszer elsősorban olyan esetekben hasznos, amikor a sok NFS-könyvtár közül csak néhányat használnak aktívan egyszerre.
E műveletek végrehajtásához az /etc/init.d/ autofs szkript automatikusan végrehajtja az automount programot a rendszer indításakor. Az /etc/auto.master fájl segítségével konfigurálható. A megfelelő programok automatikusan települnek például a Red Hat-ba és a Fedorába. Mindenesetre az autofs csak az /etc/auto.master vagy az /etc/auto.misc beállítása után engedélyezett.
cramfs és squashfs
cramfs és squashfs - A Cram és Squash fájlrendszerek csak olvashatóak. Arra használják, hogy minél több tömörített fájlt "pakoljanak" flash memóriába vagy ROM-ba (csak olvasható memória).
fuse – A FUSE a "Fájlrendszer a felhasználói térben" rövidítése, és lehetővé teszi a fájlrendszer-illesztőprogramok kernelen kívüli fejlesztését és használatát. Ezért a FUSE-t mindig külső fájlrendszer-illesztőprogrammal használják. A FUSE különösen az ntfs-3g NTFS meghajtóval működik.
gfs és ocfs – Az Oracle Global File System és az Oracle Cluster File System segítségével óriási hálózati fájlrendszereket építhetsz, amelyekhez egyszerre több számítógép is hozzáférhet párhuzamosan.
jffs és yaffs – A naplózó Flash fájlrendszer és a Yet Another Flash fájlrendszer kifejezetten a szilárdtestalapú meghajtókés flash média. Speciális algoritmusok segítségével igyekeznek egyenletesen használni az összes memóriacellát (kopásszint-kiegyenlítő technológia), hogy elkerüljék a rendszer idő előtti meghibásodását.
hurok
hurok – pszeudoeszközökkel való munkavégzésre szolgál. A visszahurkolt eszköz egy olyan adapter, amely úgy tud hozzáférni egy normál fájlhoz, mintha az blokkeszköz lenne. Neki köszönhetően bármilyen fájlrendszert elhelyezhet bármely fájlban, majd csatlakoztathatja a könyvtárfához a mount segítségével. Az ezért felelős kernel függvény - pszeudoeszköz támogatás - a ciklusmodulban van megvalósítva.
A pszeudoeszközök használatának többféle módja van. Különösen akkor használhatók, ha lemezeket hoz létre a RAM-ban a kezdeti inicializáláshoz (kezdeti RAM-lemez) a GRUB vagy a LILO számára, titkosított fájlrendszerek implementálásakor vagy CD-lemezképek tesztelésekor.
Adattároló fájlrendszerek
Fájlrendszerek
ISO 9660
Az ISO 9660 fájlrendszer Joliet kiterjesztése.
A Rock Ridge (RRIP, IEEE P1282) egy ISO 9660 fájlrendszer-kiterjesztés, amelyet a POSIX operációs rendszerekben használt fájlattribútumok tárolására terveztek.
Amiga Rock Ridge kiterjesztések
El Torito
Apple ISO9660 kiterjesztések
HFS, HFS+
Univerzális lemezformátum Az operációs rendszertől független fájlrendszer-formátum specifikációja a fájlok tárolására optikai adathordozók. Az UDF az ISO/IEC 13346 szabvány megvalósítása
Rainier-hegy
