Svim želim odličan vikend! Pozivamo vas na besplatni Demo-čas , koji će voditi Andrej Buranov — stručnjak za UNIX sustave u tvrtki Mail.Ru Group. Također objavljujemo članak Jonathana Corbeta — izvršnog urednika na LWN.net.
Jurnalizirane datotečne sustave obećavaju osloboditi sistemske administratore problema s oštećenjem diska prilikom kvara sustava. Čak i bez pokretanja provjere cjelovitosti datotečnog sustava. Iako, u stvarnosti, sve je to malo složenije. Kako pokazuje nedavna rasprava, može biti i zamršenije nego što mnogi od nas misle, jer osiguranje cjelovitosti jurnaliziranih datotečnih sustava utječe na performanse.
Datotečni sustav, poput ext3, koristi poseban prostor na disku koji se naziva dnevnik. Kada se izvrše promjene u metapodacima datotečnog sustava, te promjene se prvo bilježe u dnevniku bez modifikacije ostatka datotečnog sustava. Nakon što su sve promjene zapisane u dnevnik, dodaje se "komit blok", koji označava završetak transakcije. Tek nakon zapisivanja komit bloka, transakcija se učvršćuje, a promijenjeni metapodaci se upisuju na disk. Ako sustav u nekom trenutku prestane raditi, mogu se sigurno završiti radovi pomoću informacija iz dnevnika i izbjeći oštećenja datotečnog sustava zbog toga što su ažurirani samo neki od metapodataka.
Međutim, postoji jedan problem: kod datotečnog sustava prije zapisivanja komit bloka mora biti potpuno siguran da su sve informacije o transakciji već stigle u dnevnik. Jednostavno zapisivanje operacija u ispravnom redoslijedu nije dovoljno — moderni diskovi podržavaju velike unutarnje predmemorije i preuređuju operacije kako bi poboljšali performanse. Stoga, prije komit bloka, potrebno je izričito naznačiti prijenos svih podataka dnevnika na disk. Ako se komit blok zapiše ranije, dnevnik može biti oštećen. Za rješavanje ovog problema koriste se barijere. U osnovi, barijera zabranjuje zapisivanje bilo kakvih blokova nakon barijere dok se svi blokovi zapisani prije barijere ne prenesu na disk. Korištenjem barijera, datotečni sustavi jamče dosljednost datotečnih struktura.
No, postoji još jedan problem: datotečni sustavi ext3 i ext4 prema zadanim postavkama ne koriste barijere. Opcija postoji, ali ako administrator nije izričito uključio, ti datotečni sustavi rade bez barijera, iako u nekim distribucijama (poput SUSE) zadane vrijednosti su drugačije. Erik Sandeen nedavno je odlučio da je potrebno promijeniti ovu situaciju i , koja modificira zadane postavke za ext3 i ext4. Tada je započela žestoka rasprava.
Andrew Morton vrlo detaljno , objašnjavaći zašto je zadana vrijednost takva:
Posljednji put kada smo pokušali to promijeniti, performanse su se na mnogim opterećenjima pogoršale za 30%, pa sam u strahu odbacio sve te zakrpe. Mislim da ne možemo ići na to i značajno usporiti rad svih strojeva...
Nemamo idealna rješenja i sklon sam tome da ne budim tu uspavanu psa i ostavim zadane postavke na uvid razvojnim timovima distribucija.
Dakle, prema zadanim postavkama barijere su isključene jer ozbiljno utječu na performanse. Osim toga, datotečni sustavi se uspješno koriste bez barijera. Izvještaji o oštećenju datotečnog sustava ext3 su malo brojni i rijetki.
Ali to nije samo sreća. Ted Ts’o to je ono što je dnevnik ext3 / ext4 obično kontinuiran. Prvo, upravljački program datotečnog sustava pokušava ga stvoriti kontinuiranim. Drugo, dnevnik se obično stvara istovremeno s datotečnim sustavom, kada je lako pronaći kontinuirani prostor. Kontinuitet i urednost korisni su ne samo za performanse, već i za sprečavanje preuređenja. Obično će commit blok biti postavljen odmah nakon ostalih podataka u dnevniku, tako da disk nema razloga za preuređenje. Commit blok se prirodno zapisuje na disk odmah nakon drugih zapisa u dnevniku.
Ipak, nitko ne tvrdi da će uvijek biti tako. Diskovni uređaji mogu se ponašati drugačije. Osim toga, dnevnik predstavlja kružni međuspremnik. Kada se transakcija zapiše na kraj dnevnika, commit blok može se naći u ranijem bloku, ispred drugih zapisa u dnevniku. Dakle, uvijek postoji mogućnost oštećenja. U stvarnosti, Chris Mason ima za to Nema sumnje da je rad bez barijera manje siguran nego s njima.
Ako ste spremni na kompromis u performansama, možete uključiti barijere. U tom slučaju, naravno, kada vaš datotečni sustav nije zasnovan na LVM (kao u nekim distribucijama po defaultu). Ispostavilo se da device mapper ne podržava barijere. U ostalim slučajevima, bilo bi dobro smanjiti smanjenje performansi. Čini se da je to i moguće.
Trenutna implementacija ext3 (kada su barijere uključene) za svaku transakciju izvodi sljedeći niz operacija:
Podaci se zapisują u dnevnik
Izvodi se barijera
Zapisuje se commit blok
Izvodi se sljedeća barijera
Kasnije se metapodaci ispisuju na disk
U ext4 prvi barijer (korak 2) može se izostaviti, jer datotečni sustav ext4 podržava kontrolne zbrojeve u dnevniku.
Ako su podaci dnevnika i commit blok preuređeni, a operacija prekinuta uslijed kvara, kontrolni zbroj dnevnika neće odgovarati onome koji se čuva u commit bloku, i transakcija će biti odbijena.
Kris Mason , što bi značilo da bi bilo 'općenito sigurno' ukloniti ovu barijeru i u ext3, uz moguće izuzetke kada dnevnik dosegne kraj i počne pisati s početka.
Još jedna ideja za poboljšanje performansi je odlaganje operacija s barijerama kada je to moguće. Ako nema hitne potrebe odmah ispisivati podatke na disk, moguće je stvoriti nekoliko transakcija u dnevniku, te ispisivati na disk jednim barijerom.
Također postoji određeni potencijal za poboljšanje pažljivim redoslijedom operacija, kako bi barijere (koje se obično implementiraju kao zahtjevi 'ispisi sve odložene operacije na disk') ne forsirale zapisivanje blokova koji ne zahtijevaju redoslijed.
Izgleda da je došlo vrijeme da razmislimo kako učiniti troškove barijera prihvatljivima. Ted Tso, čini se, :
Mislim da bismo trebali uključiti barijere u ext3/4, a zatim raditi na smanjenju troškova u ext4 / jbd2. Vjerojatno velika većina sustava ne radi u uvjetima sličnim onima koje je Kris koristio za demonstraciju problema i sigurnost datotečnog sustava po defaultu trebala bi biti prioritet.
Zdrav razum mi govori da ta pas već ne spava i vjerojatno će neko vrijeme lajati. To može izazvati zabrinutost nekih susjeda, ali bolje je nego dopustiti da ugrize.
Zanima vas razvoj u ovom smjeru? Prijavite se za besplatnu Demo lekciju i sudjelujte u prijenosu , koju će voditi Pavel Vikirjuk — operater veze MVNO, DevOps inženjer.
Izvor: habr.com
