Linux file system

Što je to zapravo file/datoteka? Na najosnovnijoj razini datoteka na UNIX/LINUX sustavima je kolekcija nula ili više bitova informacija. Datoteka je osnovna, atomska jedinica informacije u datotečnom sustavu. Datoteke se dijele u direktorije , a direktoriji nisu ništa drugo doli lista datoteka koje sadrže datoteke i metapodatke koji opisuje gdje su ti direktoriji/datoteko spremljene. Na fizičkoj razini tj. razini tvrdoga diska, on vrlo malo podsjeća na datotečni sustav. Podaci se spremaju na magnetskom polju hard diska na površini diska koji ima uzorke u koje se zapisuju podaci dok se on vrti. Slično kao u glavi kazete s magnetskog vrpcom. Površina magnetne glave diska sastoji se od koncentričnih krugova (tracks) i polukrugova (sectors) unutar svake trake.

Gdje se spremaju podaci

Podaci se spremaju na čvrsti pleter, disk, koji ima magnetnu površinu. Magnetna površina podjeljena je u male magnetske dijelove , a svaka se koristi za zapis binarnog zapisa podatak. Tipična veličina magnetske regije na hard disk pleteru je oko 200-250 nanometara u polumjeru od pletera i proteže se oko 25-30 nanometara , a odgovara za optprilike 100gigabita podataka za po inču disk prostora.

Dakle datoteka je skup podataka spremljenih na disku ili nekom drugom mediju na računalu.

File sistem je način na koji računalo na logičan način imenuje i smješta datoteke i odakle ih preuzima. Razni operativni sustavi imaju različte oblike datotečnih sustava. Svima je zajedničko da se podaci smještaju u hijerarhijski oblikovanom obliku, poput drveta sa svojim granama. File sistem također uređuje pravila za imenovanje i postavke svake datoteke. Ta pravila postavljena su u inodeu, temeljnoj jedinici datotečnog sustava. Podaci koje se tako postavljaju u inodeu jesu:
       

Vlasnika i grupu Tip file-a Permisije na file-u Datum i vrijeme kreiranja, zadnje pročitano i modificiran Vrijeme i datum kad je file promijenjen u „inode“ . Broj poveznica na file Veličinu file-a Lokaciju file-a na disku

Svaki inode se može identificirati po jedisntvenom broju unutar datotečnog sustava- Inode još nazivamo broj indexa.

Možemo koristit komandu ls -i kako bismo vidjeli broj inode-a:
$ ls -i /etc/passwd

Primjer:
32820 /etc/passwd

Također možemo koristiti stat komandu da pronađemo broj inode i njezine atribute:
$ stat /etc/passwd File: `/etc/passwd' Size: 1988 Blocks: 8 IO Block: 4096 regular file Device: 341h/833d Inode: 32820 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2005-11-10 01:26:01.000000000 +0530 Modify: 2005-10-27 13:26:56.000000000 +0530 Change: 2005-10-27 13:26:56.000000000 +0530

Linux sve prepoznaje kao datoteku. Njemu ništa ne znače različite ekstenzije na koje smo navikli kod Windowsa. Postoje iznimke, tj posebne vrste datoteka , a to su:
 Direktoriji: datotke koje predstavlju listu drugih datoteka u njoj  Specijalne datoteke: mehanizmi koji služe za ulaz i izlaz podataka. Većina ih se nalazi u /dev direktoriju  Linkovi, poveznice: način kojim se omogućuje vidljivost direktorija u pojedinim dijelovima sistema  (Domain) sockets: specijalni tip datoteke, sličan TCP/IP socketu, koji omogućava internu mrežu zaštićenu sa file systemskom pristupnom kontrolom.  Named pipes:djeluju slično kao socketi te formiraju procese za komunikaciju jedni s drugima, bez semantike soketa

Temeljna struktura datotečnog sustava u Linuxu izgledala bi otprilike ovako: (izgled RedHat Linux distribucije)

Temeljna struktura datotečnog sustava krede od korijenskog direktorija. Za razliku od MS Windows operacijskog sustava koji diskove označava po slovu (C: D: E:…), te svaki takav disk ima svoje stablo direktorija, Linux sve drži unutar jednog jedinog stabla direktorija koje počinje od korijenskog (root) direktorija čija je oznaka “/” (kosa crta). Kako Linux baš sve podatke predstavlja kao datoteke (obične i posebne) unutar tog stabla direktorija, tako se onda predstavljaju i diskovi, odnosno datotečni sustavi. Opis Linux datotečnog sustava: / ili root-a . To je temeljni i korijenski direktorij, a ovlasti root-a su da on može u sustavu raditi što želi. To naravno za sobom vuče veliku i odgovornost.

Upravo iz tog razloga što se korisnici koji imaju root ovlasti mogu poigrati i srušiti cijeli sustav koji na sebi može imatii tisuće korisnika primjena root ovlasti je opravdana u veoma rijetkim situacijama, kad jednostavno nema drugog riješnja da se nešto popravi.

/sbin – Ovaj direktorij sadrži sve komande neophodne za rad sa sistemom. To uključuje komande za sistemsku administraciju kai održavanje hardwera; neki od njih su: Find lilo, fdisk, init, ifconfig. Ovo su osnovni programikoji zatjeva svaki administrator. Te komande se mogu naći i u direktoriju usr/sbin. Ovaj direktorij sadrže neke posebne komande koje koristi pojedini administrator.

/bin- suprotno od direktorija /sbin ovaj direktorija sadrži komande koje koriste kako obični korisnici Linuxa tako i administratori, kao što su: bash, csh, cp, mv, rm, cat, ls. Također postoji direktorij /usr/bin koji sadrži neke druge korisničke komande koje nisu nužne za rad. /boot – ovaj direktorij sadrži system.map datoteku kao i Linux kernel. Lilo smješta boot backup sektor u ovaj direktorij. /dev – ovaj direktorij je veoma interesantan i bitan za naglasiti. U Linuxu sve je datoteka ili direktorij. U Linuxu sve je datoteka ili direktorij. Stoga i uređaji koji su prikopčani na računalo e prikazuju kao file tj direktorij , a to se prikazuje u ovaom direkotriju. Pogledamo li kroz ovaj dirkeotrij primjetit ćemo direktorije poput: hd1, hd2 itd , koji uapravo predstavljaju različite particija glavnog hard diska. Dev/cdrom i dev/fd0 predstavljaju CDROM pogon i floppy dirve. Za početak to nam se može učinit vrlo čudnim ali zapravo to nam omogu ćava da direktono orebacujemo podatke sa jednog uređaja na drugi, npr. Uzmimo /dev/dsp koji predstavlja zvučnik. Po toj logici svaki podatak koji če biti zapisan na tom file automatski će se intepretirati kao zvuk! Pokušajmo sa 'cat /etc/lilo.conf > /dev/dsp' i trebali bismo čuti neke zvukove.Slično slanje podatka i čitanje sa /dev/ttyS0 (COM1) omogućuje komunikaciju sa uređajem spojenim tamo- tj modemom. /etc- ovaj direktorij sadrži sve konfiguracijske datoteke sistema. Lilo.conf se tamo nalazi, kao i hosts, reslov.conf i fstab. Ispod ovog direktorija nalazi se X11 poddirektorije. Još važnije /etc/rc.d direktorij sadrži sistemski startup skripte. Preporučljivo je često vršiti backup ovog direktorija. Definitivno će vam spasiti mnogo rekonfiguracije kasnije ako izgubite neke podatke ili reinstalirate.

/home – Linux je multikorisnički sustav što znači da svaki korisnik ima dodijeljen specifičan direktorij koji je dostupan samo njemu i sistemskom administratoru. To su korisnički home direktoriji, koji se mogu naći pod /home/username . Ovi direktoriji također sadrže specifične korisniče postavke programa kao što su IRC, X i sl. /lib- ovdje se nalaze sve zajedničke „biblioteke“ koje su neophodne za rad sistema i programa. Ekvivalent ovog u Windowsima bile bi DLL datoteke. /lost+found- Liunux bi uvijek trebalo pravilno gasiti. Ponekada se sistem nepravilno ugasi zbog nestanka struje ili nekog kvara, no u svakom slučaju u slijedećem bootanju računala izvršit će se provjera sustava sa fsck. Fsck proći će kroz sustav i pokušati povratiti izgubljene podatke koje nađe. Rezultat takvih nalaza smjestit će u ovaj direktorij. Mala je šansa da će oporavaljeni podaci biti kompletni i da će imati nekog smisla, ali uvijek postoji šansa da se nešto može spasiti. /mnt – ovo je generički direktorij na kojem „mountamo“ tj smještamo svoj datotečni sustav ili neki uređaj. Mounting je proces kojim datotečni sustav činimo dostupnim na računalu. Nakon mountanja datoteke će biti dostupne na toj točci gdje smo je smjestili . To obično uključuje poddirektorije gdje postaljamo svoj CD ili neki drugi uređaj. Po želji možemo dodati još tih točaka koliko trebamo, i nema ograničenja da ih msjestimo bilo gdje na sustavu. /opt- ovaj direktorij sadrži sve software i dodatne pakete koji nisu dio osnovne instalacije OS-a. Tu ćemo obično naći KDE i StartOffice . /proc- Ovo je posebni direktorij na sistemu. /root – Ne treba brkati korijenski direktorij / sa direktorijem /root jer su to dva različita direktorija. /root je home direktorij root usera. /tmp – ovaj direktorij sadrži datoteke koje se priveremno nalaze na sistemu. Mnogi programi koriste ovaj direktorij kako bi privremeno smjestili svoje podatke tamo. Na nekim sistemima se ti podacia automatski brišu pri svakom svakom bootoanju il nakon nekog vremena koji se odredi. /usr – Ovo je jedan od najvažnijih direktorija na sistemu, koji sadrži sve podatke korisnika. Korisnički programi kao što su telnet, ftp, itd takođes su smješteni ovdje.

/usr/doc – sadrži korisnu sistemsku dokumantaciju. /usr/src/linux saddrži soorce-code za linux kernel. /var- Ovaj direktorij sadrži spolling datoteke kao što su mail i printer. Sistemski logovi se također ovdje zapisuju /var/log/messages. Također ovjde ćete naću bazu podatka za BIND u /var/named.

Linux je monolitni operativnu sustav što znači da se cijela hijerathije direktorijagrana iz jednog (root) direktorija. To nije tako kod drugih operatinvih sustava kao što je to Windows npr. Upravo zbog te karakteristike moramo posebnu pažnju posvetiti particijama na Linuxu. Particije su logički podijeljeni dijelovi tvrdog diska. Particije se u Linux-u razlikuju od particija u Windowsima. Dok bi kod Windows operativnog sustava ova hijerarhija operativnog sustava bilo moguće instalirati isključivo na jednoj particiji, na linuxu možemo, a i poželjno je odvojiti / root od /home direktorija sa odvojenom particijom. Razlozi za to su mnogi, a jedan od njih je što se time ostvaruje veća sigurnost sustava, lakše osigurava manipulacija prostorom na disku i sl.

Datotečni sustavi
Da bismo spremali svoje podatke u organiziranom obliku datoteka i direktorija na particiju je potrebno postaviti datotečni sustav. Za razliku od nekih drugih operacijskih sustava Linux ima popriličan broj raznih datotečnih sustava koje možemo koristiti prema vlastitim potrebama. Neki bitniji datotečni sustavi su ovdje: Ext4: Linuxov uobičajeni datotečni sustav ReiserFS: Linuxov manje zastupljeni datotečni sustav NTFS: Datotečni sustav kojeg koriste MS Windows. Linux može raditi sa ovim datotečnim sustavom. FAT: njega pronalazimo na gotovo svim USB stickovima ISO 9660 i UDF: su datotečni sustavi CD/DVD diskova Osim spremanja podataka, datotečni sustavi nude još neke opcije pri radu s podacima kao što su linkovi i journaling. Više o Ext4 datotečnom sustavu:

    

1. Uvod za Ext4
Ext4 je evolucijski napredak najkorištenijeg linuxovog datotečnog sustava , Ext3. Ext4 je značajno poboljšan u odnosu na Ext3. Ext3 se u odnosu spram prethnodog Ext2 datotečnog sustava poboljšao samo u odnosu mogućnosti „journalinga“, dok se Ext4 poboljšao u nizu stvari kao što su bolja podatkovna struktura kao ona

namjenjena spremanju datoteka. Rezultat toga je datotečni sustav sa poboljšanim dizajnom , performansama, pouzdanošću i karakteristikama.

2. EXT4 karakteristike 2.1. Kompatibilnost
Jedna od odličnih stvari kod Ext4 datotečnog sustava je mogućnost lagane migracije sa postojećeg Ext3 datotečnog sustava. To drugim riječima znači da možete poboljšati performase svog sustava bez ikakve tehničke preinake samom promjenom na Ext4. To je pogotovo dobro za produkcijske sustave koji tako bez rizika značajno poboljšavaja svoje performase. Es će ostaviti nedirnute podatke, a jednom kad te podatke pretvorite u Ext4 datotečni sustav nećete se moći vratiti na Ext2 ( a vjerojatno nećete ni htjeti  ). Možete jedino montirati Ext3 unutar Ext4 datotečnog sustava..

2.2. Veći datotečni sustav
Currently, Ext3 support 16 TB of maximum filesystem size, and 2 TB of maximum file size. Ext4 adds 48-bit block addressing, so it will have 1 EB of maximum filesystem size and 16 TB of maximum file size. 1 EB = 1,048,576 TB (1 EB = 1024 PB, 1 PB = 1024 TB, 1 TB = 1024 GB). Why 48-bit and not 64-bit? There are some limitations that would need to be fixed before making Ext4 fully 64-bit capable, which have not been addressed in Ext4. The Ext4 data structures have been designed keeping this in mind, so a future update to Ext4 will implement full 64-bit support at some point. 1 EB will be enough (really until that happens. (Note: The code to create filesystems bigger than 16 TB is -at the time of writing this article- not in any stable release of e2fsprogs. It will be in future releases.) Ext3 podržavao je 16TB maksimallnu veličinu datotečnog sustava i 2 TB maksimalnu veličinu jedne datoteke. Ext3 je tu značajno napravio iskorak. Dodao je 48-bitne adresne blokove, tako da podržava maksimalnu veličinu datotečnog sustava od 1EB i 16TB za maksimalnu veličinu jedne datoteke. (1 EB = 1024 PB, 1 PB = 1024 TB, 1 TB = 1024 GB). Zašto se koristi 48-bitne a ne 64-bitne adresni blokovi?. Potrebno je prije toga riješiti određene ogranićenja kako bi Ext4 bio potpuno 64-bitno kompatibilan. Na ovome se radi. Do tada 1EB mislim da je sasvim zadovoljavajuće 

2.3. Skalabilnost poddirektorija
Right now the maximum possible number of sub directories contained in a single directory in Ext3 is 32000. Ext4 breaks that limit and allows an unlimited number of sub directories. Ext3 je imao maksimalno 32000 poddirektorija. Ext4 prelazi tu granicu i daje mogućnost da se teoetski otvara neograničen broj poddirektorija.

2.4. Extenti
Tradicionalno su linux datotečni sustavi poput Ext3 koristili indirektrno mapiranje blokova kako bi imali shemu gdje se podaci nalaze na disku. To je pogotovo utjecalo na velike datoteke, pogotovo pri nekim operacijama što je dovodilo do sporosti sistema. Naime svaki blok, a kad ih je puno treba pregledati i izbristai ili promjeniti ovisno o operaciji. Moderniji datotečni sustavi kao što su Ext4 koriste „extents“. Oni rade tako da alociraju podatke na određenoj regiji diska, to je drugim riječim hrpa neposredno povezanih blokova. U osnovi kaže računalu :“Podaci su ti i slijedećm n bloku“. Npr datoteka od 100mb može se alocirati u jedan extent, umjesto potrebe da se stvara indirektno mapiranje za 25300 blokova (4KB po bloku). Velike datoteke razdjeljene su u nekoliko extenta. Extenti povećavaju performanse i smanjuju fragmentiranost , jer oni podržavaju doslijednost datoteka na disku.

2.5. Multiblock allocation
When Ext3 needs to write new data to the disk, there's a block allocator that decides which free blocks will be used to write the data. But the Ext3 block allocator only allocates one block (4KB) at a time. That means that if

the system needs to write the 100 MB data mentioned in the previous point, it will need to call the block allocator 25600 times (and it was just 100 MB!). Not only this is inefficient, it doesn't allow the block allocator to optimize the allocation policy because it doesn't knows how many total data is being allocated, it only knows about a single block. Ext4 uses a "multiblock allocator" (mballoc) which allocates many blocks in a single call, instead of a single block per call, avoiding a lot of overhead. This improves the performance, and it's particularly useful with delayed allocation and extents. This feature doesn't affect the disk format. Also, note that the Ext4 block/inode allocator has other improvements, described in detail in this paper.

2.6. Delayed allocation
Delayed allocation is a performance feature (it doesn't change the disk format) found in a few modern filesystems such as XFS, ZFS, btrfs or Reiser 4, and it consists in delaying the allocation of blocks as much as possible, contrary to what traditionally filesystems (such as Ext3, reiser3, etc) do: allocate the blocks as soon as possible. For example, if a process write()s, the filesystem code will allocate immediately the blocks where the data will be placed - even if the data is not being written right now to the disk and it's going to be kept in the cache for some time. This approach has disadvantages. For example when a process is writing continually to a file that grows, successive write()s allocate blocks for the data, but they don't know if the file will keep growing. Delayed allocation, on the other hand, does not allocate the blocks immediately when the process write()s, rather, it delays the allocation of the blocks while the file is kept in cache, until it is really going to be written to the disk. This gives the block allocator the opportunity to optimize the allocation in situations where the old system couldn't. Delayed allocation plays very nicely with the two previous features mentioned, extents and multiblock allocation, because in many workloads when the file is written finally to the disk it will be allocated in extents whose block allocation is done with the mballoc allocator. The performance is much better, and the fragmentation is much improved in some workloads.

2.7. Fast fsck
Fsck is a very slow operation, especially the first step: checking all the inodes in the file system. In Ext4, at the end of each group's inode table will be stored a list of unused inodes (with a checksum, for safety), so fsck will not check those inodes. The result is that total fsck time improves from 2 to 20 times, depending on the number of used inodes (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). It must be noticed that it's fsck, and not Ext4, who will build the list of unused inodes. This means that you must run fsck to get the list of unused inodes built, and only the next fsck run will be faster (you need to pass a fsck in order to convert an Ext3 filesystem to Ext4 anyway). There's also a feature that takes part in this fsck speed up - "flexible block groups" - that also speeds up filesystem operations.

2.8. Journal checksumming
The journal is the most used part of the disk, making the blocks that form part of it more prone to hardware failure. And recovering from a corrupted journal can lead to massive corruption. Ext4 checksums the journal data to know if the journal blocks are failing or corrupted. But journal checksumming has a bonus: it allows one to convert the two-phase commit system of Ext3's journaling to a single phase, speeding the filesystem operation up to 20% in some cases - so reliability and performance are improved at the same time. (Note: the part of the feature that improves the performance, the asynchronous logging, is turned off by default for now, and will be enabled in future releases, when its reliability improves)

2.9. "No Journaling" mode
Journaling ensures the integrity of the filesystem by keeping a log of the ongoing disk changes. However, it is known to have a small overhead. Some people with special requirements and workloads can run without a journal and its integrity advantages. In Ext4 the journaling feature can be disabled, which provides a small performance improvement.

2.10. Online defragmentation
While delayed allocation, extents and multiblock allocation help to reduce the fragmentation, with usage filesystems can still fragment. For example: You write three files in a directory and continually on the disk.

Some day you need to update the file of the middle, but the updated file has grown a bit, so there's not enough room for it. You have no option but fragment the excess of data to another place of the disk, which will cause a seek, or allocate the updated file continually in another place, far from the other two files, resulting in seeks if an application needs to read all the files on a directory (say, a file manager doing thumbnails on a directory full of images). Besides, the filesystem can only care about certain types of fragmentation, it can't know, for example, that it must keep all the boot-related files contiguous, because it doesn't know which files are bootrelated. To solve this issue, Ext4 will support online fragmentation, and there's a e4defrag tool which can defragment individual files or the whole filesystem.

2.11. Inode-related features
Larger inodes, nanosecond timestamps, fast extended attributes, inodes reservation...

 Larger inodes: Ext3 supports configurable inode sizes (via the -I mkfs parameter), but the default inode
size is 128 bytes. Ext4 will default to 256 bytes. This is needed to accommodate some extra fields (like nanosecond timestamps or inode versioning), and the remaining space of the inode will be used to store extend attributes that are small enough to fit it that space. This will make the access to those attributes much faster, and improves the performance of applications that use extend attributes by a factor of 3-7 times.

 Inode reservation consists in reserving several inodes when a directory is created, expecting that they
will be used in the future. This improves the performance, because when new files are created in that directory they'll be able to use the reserved inodes. File creation and deletion is hence more efficient.

 Nanoseconds timestamps means that inode fields like "modified time" will be able to use nanosecond
resolution instead of the second resolution of Ext3.

2.12. Persistent preallocation
This feature, available in Ext3 in the latest kernel versions, and emulated by glibc in the filesystems that don't support it, allows applications to preallocate disk space: Applications tell the filesystem to preallocate the space, and the filesystem preallocates the necessary blocks and data structures, but there's no data on it until the application really needs to write the data in the future. This is what P2P applications do in their own when they "preallocate" the necessary space for a download that will last hours or days, but implemented much more efficiently by the filesystem and with a generic API. This has several uses: first, to avoid applications (like P2P apps) doing it themselves inefficiently by filling a file with zeros. Second, to improve fragmentation, since the blocks will be allocated at one time, as contiguously as possible. Third, to ensure that applications always have the space they know they will need, which is important for RT-ish applications, since without preallocation the filesystem could get full in the middle of an important operation. The feature is available via the libc posix_fallocate() interface.

2.13. Barriers on by default
This is an option that improves the integrity of the filesystem at the cost of some performance (you can disable it with "mount -o barrier=0", recommended trying it if you're benchmarking). From this LWN article: "The filesystem code must, before writing the [journaling] commit record, be absolutely sure that all of the transaction's information has made it to the journal. Just doing the writes in the proper order is insufficient; contemporary drives maintain large internal caches and will reorder operations for better performance. So the filesystem must explicitly instruct the disk to get all of the journal data onto the media before writing the commit record; if the commit record gets written first, the journal may be corrupted. The kernel's block I/O subsystem makes this capability available through the use of barriers; in essence, a barrier forbids the writing of any blocks after the barrier until all blocks written before the barrier are committed to the media. By using barriers, filesystems can make sure that their on-disk structures remain consistent at all times."

Sign up to vote on this title
UsefulNot useful