Operációs rendszerek Eset-tanulmányok fájlrendszerekről
A mai program • Az NTFS fájlrendszer
Vadász
2
Az NTFS fájlrendszer • Célok a fejlesztésében – Korábbi fs-ek korlátainak meghaladása (FAT és HPFS max 4 GB) – A védelem javítása (kiterjesztett ACL) – Tömörítés (átlátszóan) – Titkosítás (átlátszóan) – Szétszabdaltság (fragmentation) megszüntetése – Diszk tranzakció naplózás és visszaállítás beépítése – Kötet (Volume Set, Strip Set, Mirror Set: utóbbi hibatűrés) koncepció
Vadász
3
1
NTFS koncepciók • A diszk klaszter koncepció (cluster) – A fizikai felépítéstől függetlenül, egy kötet klaszterek készlete. – Egy klaszter 2 hatványa * 512 bájt. Ajánlott klaszter méretek a diszkekhez – A Logical Cluster Number (LCN) fogalom: egy kötet 0 – n LCN-ű klaszterekből áll – Virtual Cluster Number (VCN) fogalom: egy (nem rezidens) adatfolyam klasztereinek is van sorszáma. Az adatfolyam klaszterei 0, 1, 2 stb. VCN sorszámokat vehetnek fel. Vadász
4
NTFS koncepciók2 • Az NTFS fájlrendszeren minden fájl. Vannak – Normális fájlok (köztük jegyzékek és adatfájlok), és – A fájlrendszerrel kapcsolatos információkat tartalmazó fájlok: metafájlok. – A metafájlok közül legfontosabb a Master File Table (MFT)
• Minden fájlhoz tartozik (legalább) egy MFT rekord (bög) – Az MFT rekordokban fájl-attribútumokat rögzítenek (Az MFT rekord az s5fs i-bögjének felel meg. Az MFT leginkább az i-lista megfelelője.)
Vadász
5
NTFS koncepciók3 • Minden fájlhoz tartozik egy hivatkozási szám – 64 bites szám alsó 48 bitje az MFT rekord „pozíciója” (indexe), – a felső 16 bit egy sorozatszám, ami növekszik, mikor a megfelelő MFT rekordot újrafelhasználják. (A hivatkozási szám az s5fs i-bög i indexének felel meg.)
• A jegyzék (directory) szerkezetről elöljáróban annyit: B-fa rendezettségű, a „név + a hivatkozási számot is tartalmazó szabványos attribútumok” párok gyűjteménye. (Valójában a jegyzék is egy fájl: attribútumok együttese.) Vadász
6
2
NTFS koncepciók4 • Az NTFS a fájlokat attribútumok együtteseként látja. • Egy attribútum: attr.fej + attr.adatok pár – Attribútum fej tartalma • az attribútum típusa (neve opcionálisan), • flagek és • Az attribútum adatai elhelyezkedésére vonatkozó információk.
– Attribútum adatok: a tényleges „tulajdonságok”
• Két fontos „trükk” – Egy fájl adatfolyama (data stream) is attribútum! – Amikor csak lehet, egy attribútumot az MFT rekordjában (a bögjében) tárolják! Vadász
7
NTFS koncepciók összefoglalás • Egy kötet klaszterek sora. LCN fogalom. • Minden fájl (metafájlok + fájlok), MFT rekord (bög) tartozik hozzájuk, index az MFT-ben • Attribútumok együtteseként kezelhetők a fájlok (attr-fej+attr-adat) • Az adatfolyam is attribútum! • Amikor csak lehet, az attribútumot az MFT rekordban tárolják!
Vadász
8
NTFS koncepciók5 • Rezidens attribútum: ami az MFT rekordban tárolódott – A fájlnév, a szabványos információk, a biztonsági attribútumok mindig rezidensek – Az adatok csak akkor rezidensek, ha rövid a fájl …
• Nem rezidens attribútum: aminek MFT rekordon kívüli helyfoglalása van: kiterjedésekben (runs) tárolódnak az adatai • Kiterjedés (run) valahány egymás utáni klaszter. Megadható kezdő LCN-jével és hosszával: ez a kiterjedés leírás (data runs) Vadász
9
3
NTFS koncepciók6 • Láttuk, ha egy fájlnak attribútum adata „túl nagy”, nem rezidens attribútumként tárolják. • Nem rezidens attribútum az MFT rekordban attribútum adatok elhelyezkedésére vonatkozó információként (kiterjedés leírásként) tárolódik. • Ha egy fájlnak túl sok attribútuma van és nem férnek el az MFT rekordban – Akkor amit lehet, nem rezidenssé tesznek. – Ha ekkor sem férnek el: további (additional) MFT rekordot allokálnak neki, ebbe tesznek attribútumokat; – Az eredeti (base) MFT rekordba attribútum lista attribútum kerül. Vadász
10
MFT rekordok • Egy MFT rekord – Lehetséges attribútumokat később
Kiterjedés leírás attr
• A mark.txt relatíve nagy és fregmentált fájl – Base MFT rek, additív MFT rek; kiterjedések leírása itt is, ott is …
• Egy jegyzék rekord – 1 db root index – Valahány Index allocation – Valahány Bitmap (nem látszik az ábrán) Vadász
11
Attribútumok Attribute Type
Description
Standard Information
Includes information such as timestamp and link count.
Attribute List
Lists the location of all attribute records that do not fit in the MFT record.
File Name
A repeatable attribute for both long and short file names. The long name of the file can be up to 255 Unicode characters. The short name is the 8.3, case-insensitive name for the file. Additional names, or hard links, required by POSIX can be included as additional file name attributes.
Security Descriptor
Describes who owns the file and who can access it.
Data
Contains file data. NTFS allows multiple data attributes per file. Each file typically has one unnamed data attribute. A file can also have one or more named data attributes, each using a particular syntax. Vadász
12
4
Attribútumok Attribute Type
Description
Object ID
A volume-unique file identifier. Used by the distributed link tracking service. Not all files have object identifiers.
Logged Tool Stream
Similar to a data stream, but operations are logged to the NTFS log file just like NTFS metadata changes. This is used by EFS.
Reparse Point
Used for volume mount points. They are also used by Installable File System (IFS) filter drivers to mark certain files as special to that driver.
Index Root
Used to implement folders and other indexes.
Index Allocation
Used to implement folders and other indexes.
Bitmap
Used to implement folders and other indexes.
Volume Information
Used only in the $Volume system file. Contains the volume version.
Volume Name
Used only in the $Volume system file. Contains the volume label. Vadász
File Name
MFT Rec
13
Metafájlok
Purpose of the File
$Mft
0
Contains one base file record for each file and folder on an NTFS volume. If the allocation information for a file or folder is too large to fit within a single record, other file records are allocated as well.
$MftMirr
1
A duplicate image of the first four records of the MFT. This file guarantees access to the MFT in case of a single-sector failure.
$LogFile
2
Contains a list of transaction steps used for NTFS recoverability. Log file size depends on the volume size and can be as large as 4 MB. It is used by Windows NT/2000 to restore consistency to NTFS after a system failure.
$Volume
3
Contains information about the volume, such as the volume label and the volume version.
$AttrDef
4
A table of attribute names, numbers, and descriptions.
$
5
The root folder.
$Bitmap
6
A representation of the volume showing which clusters are in use.
$Boot
7
Includes the BPB used to mount the volume and additional bootstrap loader code used if the volume is bootable.
$BadClus
8
Contains bad clusters for the volume.
$Secure
9
Contains unique security descriptors for all files within a volume.
$Upcase
10
Converts lowercase characters to matching Unicode uppercase characters.
11
Used for various optional extensions such as quotas, reparse point data, and object identifiers. Vadász
$Extend
14
12–15 Reserved for future use.
Metafájlok: MFT • Figyeljünk az MFT „önhivatkozó” jellegére! A 0-s rekordja saját magát írja le! • A 0-s rekordban attribútumok: – – – –
Standard Information File Name Data (Hol van az MFT) Bitmap (Az MFT mely bögei foglaltak)
• MFT „rezervációs zóna” – A kötet foglaltságtól is függően lefoglalt terület az MFT „körül”, hogy az MFT „nőhessen” Vadász
15
5
Egy NTFS kötet $Boot
$Mft
…szabad … $MftMirr …szabad … $Boot
Vadász
16
Kérdések az MFT-vel kapcsolatban • Kérdés1: Lehet-e az MFT 0-s rekordban nem rezidens attribútum? Ha igen, valószínű ilyen? Melyik? • Kérdés2: Hány kiterjesztése lehet az MFT-nek? Csak egy? • Kérdés3: Lehet-e a 0-s rekordban Attributum-list attribútum? Ha igen, valószínű-e?
Vadász
17
NTFS irodalom http://www.ntfs.com http://www.linux-ntfs.org/ Russinovich: Inside NTFS, http://www.windowsitpro.com/Article/ArticleID/3455 /3455.html Harwel, Webb, Flynn, Whitehurst: Unix and Windows 2000 Handbook, Prentice Hall, 2000
Vadász
18
6
Milyen Unix-os fájlrendszereket ismerünk? • • • • • • • •
A tradicionális s5fs 4.2BSD FFS (Fast, az előbbi alternatívájaként) AT&T RFS (Remote FS) Sun NFS Linux ext2 stb. DOS VFAT Érdekes a Sun vnode/vfs rendszere – Sokféle fs, mégis egységes képet mutassanak … – Hálózaton át is lehessen fs-eket megosztani … – A gyártók a vfs alá modulárisan valósítsák meg saját fs-eiket Vadász
19
A Berkeley Fast FS • Oldal (fej)-sáv-szektor fogalmakat ismerjük • A cilinder fogalmat is. – SCSI diszkeknél? Ott sávcsoportonként változó szektorszám van!
• A Unix lineáris (logikai) blokkcímeket lát a partíción … • A partíciók egymás utáni (consecutive) cilindereken … – LBN „növekedésnél” • Először nő a szektorszám, • Aztán az oldalszám, • Végül a sáv (cil) szám … Vadász
20
Az FFS-hez • Új fogalom a cilinder csoport (cyl group) – Cilinder csoporton belül kis fejmozgás
• A tradicionális su-blokk 2 struktúrára – Információk az egész fájlrendszerről (cil-csop-szám, méret, hely; blokk méret, i-bög szám stb.), – Információk a cil-csop-ról (szabad i-bögök, szabad blokk lista stb.)
• Cil-csoportonként másolat a su-blokkról! – Biztonság is cél az elhelyezésénél.
Vadász
21
7
Az FFS-hez • Új fogalom a töredék (fragment) – Növelt blokkméret, nagyobb lehetséges veszteség – A blokkméret: 4096/8192 (s5fs: 512/1024) • Ezzel 2 szintű indirekcióval már lehet 4GB-os fájl
– A fragment méret is fix (fs kreációnál beállítható: 1-2-4-8 fragment/blokk) – Minden fragment önállóan címezhető, allokálható
Vadász
22
Egy FFS fájl • Állhat – Valamennyi blokkból, + – Az utolsó blokkban valamennyi egymás utáni (consecutive) fragmentből …
• Emiatt néha fájl recopying kell! – Pl. f1 fájl utolsó adatai egy blokk egy fragmentje. Lehet, e blokk további fragmentjei más fájlokéi. – Ha f1 növekszik, utolsó blokkjának új blokkot kell allokálni (pl. ahol elegendő consecutive fragment van), oda azt a bizonyos fragmentet átmásolni, további fragmentek allokálhatók … – Ez veszteség. Vadász
23
FFS allokációs politika • Egy dir-be tartozó fájlok i-bögjei lehetőleg egy cilinder csoportba kerüljenek (gyorsítás) • Új dir kreáláskor azt a szülő dir cil-csop-jától különböző csoportba („egyenletes” elosztás) • Fájl blokkjai lehetőleg ua. cil-csopból, mint ahol i-böge van (gyorsítás) • Egy cil-csopot lehetőleg ne töltsön ki egy nagy fájl (nagyra növő fájlnál más csoportba allokálnak) • Fájl egymás utáni blokkjai allokálásánál interleaving • Ez a politika 90%-os telítettségig jó (Az FFS-nél vezették be a hosszú fájlneveket, a dir-beli chunkokat) Vadász
24
8
A Linux többrétegű fájlrendszere Process 1
Process 2
Process n
...
User mode Kernel mode
VIRTUAL FILE SYSTEM ext2
msdos
minix
...
proc
Buffer cache File System
Device drivers
Vadász
25
A Linux fájlrendszer • A VFS a rendszerhívásokat átalakítja az adott fájlrendszerre nézve specifikus hívássá • Van (lehet) – – – – – – – –
Second Extent (ext2): a Linux sajátja MSDOS: VFAT Minix (mert Minixből fejlődött a Linux) AFF (Amiga Fast FS) ufs & s5fs (szokásos UNIX) HPFS (OS/2) NTFS (NT, béta verzióban) és a proc (ami egész különleges, de nem a Linux találta ki) Vadász
26
Tovább a fájlrendszeren • Mindegyik implementált fájlrendszerhez a VFS-en keresztül juthatunk • A VFS absztrakt felület minden fájl operációhoz • A VFS szinten minden fájlhoz kernel i-bög tartozik. A kernel i feltétlenül egyedi. • A köteteken lévő i-bög (már ha van) különbözhet a kernelbeli i-bögtől • Egységes buffer cache-elés van (már ahol ennek van értelme)
Vadász
27
9
Az ext2 • Története – – – –
Kezdetben Minix FS: max 64 MB, 14 hosszú nevek 1992: ext: 2GB, 255-ös nevek (lassú, fregmentáló) 1993: xia: 2GB, 248-as nevek, bit-térképes 1993: ext2 • • • • • • •
BSD Fast FS hatása: a partíció blokk csoportokból áll. A block group-okon szuperblokk másolat van, a block group-oknak saját bit térképük van, a block group-oknak saját i-listjük van, a block group-oknak saját i-bög térképük is. Ezzel az adatblokkok közel vannak az i-bögjükhöz, továbbá a fájl i-bögök közel vannak a jegyzékük i-bögjéhez. Vadász
28
Az ext2 partíció szerkezete Itt a "fizikai szuperblokk" is: i-bög szám, blokk szám, szabad i-bög szám, státus stb.
Boot blk
Blok group 0
Super Group blokk descriptor
Blok group 1
Block bitmap
Su-blokk másolat
I node bitmap
Block bitmap size I node table size No. of free inodes
...
Blok group n
I node table
Data blocks
I node bitmap size No. of free blks No. of dirs
Vadász
29
A blokk-csoport leíró • Group descriptor: 32 byte – – – – – –
Block bitmap: az blokk térkép mérete blokkokban Inode bitmap: az i-bög térkép mérete blokkokban Inode table: az i-lista mérete blokkokban No. of free blks: szabad blokkok száma No. of free inodes: szabad i-bögök száma No. of dirs: jegyzékek száma
• I-bög allokáció – Fájl i-böge közel a jegyzékéhez (lehetőleg ugyanabban a blokk-csoportban) – Jegyzék i-böge: olyan blokkcsoportban, ahol kicsi a jegyzékek száma (elszórtan a köteten) Vadász
30
10
I-bög szerkezet 0 8 16 24 32 40 88 96 104 112 120
0 1 2 3 Type/perm. User (uid) Access time Time of modification Group (gid) Link counter File attributes
4 5 6 File size Time of creation Time of deletion Number of blocks Reserved
7
12 direct blocks pointer One-stage indirect block Three-stage indirect block File ACL Fragment address
Two-stage indirect block File version Directory ACL
További fájl attribútumok lehetnek a standard Unix attribútumok mellett. Az ACL és a visszaállítási lehetőség csak tervezett. Vadász
31
A jegyzék szerkezet i-bög 1
12
1
név hossz .
hossz
2
12
1
..
11
20
10 lost+found
név
• Nem "valódi" láncolt lista • Törléskor az előző bejegyzés hosszát növelik – Nincs "shift" és nincs "üres" bejegyzés
• Beíráskor egy bejegyzést "megoszthatnak" Vadász
32
A blokk allokáció • Cél: a fregmentáció elkerülése • Algoritmus (l: utoljára allokált a fájl (n-1)-edik blokkja) – – – – –
ha a "cél-blokk" szabad, azt allokálják, különben a "cél-blokk" 32 blokknyi "közelében" allokálnak, ha itt sincs szabad, a "cél-blokk" block-group-ján belül, és csak ezután más blokk csoportból. (Cél orientált allokáció) Ha allokálnak egy blokkot, az azt követő 8 blokkot prezerválják (más fájlok elől ideiglenesen "elzárják"). (Pre-allocation) – A cél-blokk: az (l+1)-edik blokk, (itt egy heurisztikus alg.,) vagy annak a blokkcsoportnak első szabad blokkja, amelyiken a fájl i-böge van
Vadász
33
11
Végül a proc fájlrendszerről • Állapot információkat szolgáltat a kernelről és a processzekről • Minden processzhez tartozik /proc/pid jegyzék – ebben "fájlok", a pid-ű processz státusát adják – A map fájl a processz virtuális címtérképe.
• További "fájlok" (pl.: loadavg, uptime, meminfo, kmsg, version, cpuinfo, mounts stb.) a kernel állapotról informálnak • Nem tartozik hozzá eszköz! (nodev típus) – Mégis, készíthetünk róla (és aljegyzékeiről) az ls paranccsal listát! Fájljait kiírathatjuk! Az on-line man-nal a tartalmuk értelmezéséről érdeklődhetünk. Vadász 34
12
