XFS- Silicon Graphicsi poolt välja töötatud, kuid nüüd välja antud ajakirjade failisüsteem avatud lähtekoodiga(avatud lähtekoodiga).

Ametlik teave kohta http://oss.sgi.com/projects/xfs/

XFS-i lõi 90ndate alguses (1992–1993) Silicon Grapgics (praegu SGI) Irix OS-i kasutavate multimeediumiarvutite jaoks. Failisüsteem oli suunatud väga suurtele failidele ja failisüsteemidele. Selle failisüsteemi eripäraks on ajakirjade seade – osa failisüsteemi enda metaandmetest kirjutatakse päevikusse nii, et kogu taastamisprotsess taandub nende andmete kopeerimiseni ajakirjast failisüsteemi. Logi suurus määratakse süsteemi loomisel, see peab olema vähemalt 32 megabaiti; ja te ei vaja rohkem – nii palju sulgemata tehinguid on raske saada.

Mõned funktsioonid:

Töötab tõhusamalt suurte failidega.

Sellel on jõudluse parandamiseks võimalus logi teisele kettale teisaldada.

Salvestab vahemälu andmed ainult siis, kui mälu on täis, mitte perioodiliselt nagu teised.

Logitakse ainult metaandmeid.

Kasutatakse B+ puid.

Kasutab loogilist logimist

11.6.4 rfs failisüsteem

RFS (RaiserFS)- Namesysi välja töötatud ajakirjade failisüsteem.

Ametlik teave kohta RaiserFS

Mõned funktsioonid:

Töötab jõudluse ja kasutamise tõhususe osas tõhusamalt suure hulga väikeste failidega kettaruumi.

Kasutab spetsiaalselt optimeeritud b* tasakaalustatud puud (B+ puu täiustatud versioon)

Jaotab dünaamiliselt i-sõlmed nende staatilise komplekti asemel, mis loodi "traditsioonilise" failisüsteemi loomisel.

Dünaamilised plokkide suurused.

11.6.4 jfs failisüsteem

JFS (ajakirjas Failisüsteem) - Päevikufailisüsteem, mille IBM on välja töötanud AIX operatsioonisüsteemi jaoks, kuid on nüüd välja antud avatud lähtekoodiga.

Ametlik teave Ajakirjastatud failisüsteemi tehnoloogia Linuxi jaoks

Mõned funktsioonid:

JFS-i logid järgivad klassikalist andmebaasi tehingumudelit

Logitakse ainult metaandmeid

Logi suurus ei ületa 32 megabaiti.

Asünkroonne logimisrežiim – tehakse siis, kui I/O liiklus väheneb

Kasutatakse loogilist logimist.

11.7 Mõne kaasaegse failisüsteemi võrdlustabel

Failisüsteemi valik on alati olnud Linuxi poolehoidjate seas tuliselt vaieldud teema, kes löövad vastu rinda, püüdes veenda oma vastaseid, et nad eksivad täielikult. Ja see on enam kui arusaadav, sest erinevalt Windowsist või macOS-ist, kus kasutajad ei pea oma igapäevaste arvutiseikluste käigus sellele palju vähem mõtlema, ei ole sellel operatsioonisüsteemil puudust erinevaid valikuid failisüsteem. Kuigi ext on enamiku jaoks vaikeseade Linuxi distributsioonid, XFS-i tõenäoliselt ei tõstata tagasi ja on Linuxi maailmas väga populaarne. Aga mis see failisüsteem on ja mille poolest see erineb oma kaaslastest?

XFS on tegelikult üks vanimaid ja küpsemaid failisüsteemid, saadaval Linuxi jaoks. Seda arendas Silicon Graphics ja tutvustas 1994. aastal koos nendega operatsioonisüsteemi IRIX, siirdus see 2001. aastal Linuxi tuumale eesmärgiga hallata edukalt tohutuid andmemahtusid. Vorming oli pikka aega valikuline ja valiti lõpuks punase jaoks vaikimisi Hat Enterprise Linux 7 2014. aastal. Seda toetab praegu enamik Linuxi distributsioone, samas kui RHEL, Oracle Linux 7, CentOS 7 ja mõned teised kasutavad seda vaikefailisüsteemina.

XFS on 64-bitine ajakirjanduse failisüsteem. Iga XFS-faili sisu salvestatakse kettal olevates andmeplokkides. Et salvestada tõhusalt kõike, mida esile tõstad ja vaba ruumi XFS rühmitab need plokid külgnevateks jadadeks, mida nimetatakse ulatusteks ja mida failisüsteem saab lahendada üksikute üksustena. Minimaalne suurus Ulatus on üks plokk ja see võib faili suuruse kasvades kasvada. Kogu teave faili kohta (selle metaandmed) salvestatakse spetsiaalsesse andmestruktuuri, mida nimetatakse inoodiks. Failisüsteem ise koosneb kolmest põhikomponendist:

Andmete jaotis kasutatakse kõigi failisüsteemi metaandmete ja kasutajaandmete (va reaalajas failid) salvestamiseks. See partitsioon on jagatud teatud arvuks võrdse suurusega jaotusrühmadeks (saate eelnevalt määratleda nende arvu või suuruse - miinimum on 16 MB ja maksimum on kuni terabait). Iga jaotusrühma võib pidada eraldi failisüsteemiks, mis kontrollib iseseisvalt oma ruumi kasutamist. Mitu jaotusrühma võimaldavad XFS-il käsitleda mitut toimingut samaaegselt ilma jõudlust halvendamata. Jälgimiseks vaba ruumi Iga jaotusrühm kasutab spetsiaalsete struktuuride paari, mida nimetatakse B+ puudeks, mille sõlmed sisaldavad teavet iga vaba ala lähteploki ja selle suuruse kohta plokkides. Sama lähenemisviisi kasutatakse iga faili andmeplokkide ja inoodide jälgimiseks.

Palkide sektsioon sisaldab kogu logimisteavet, mis kirjutatakse failisüsteemi metaandmete muudatuste tegemisel ja säilitatakse seal kuni nende lõpetamiseni: äkilise krahhi või elektrikatkestuse korral võimaldab see lõpetada kõik sel hetkel tehtud toimingud ja seeläbi failisüsteemi järjepidevuse säilitamine.

Reaalajas sektsioon salvestab reaalajas failiandmeid – failid, mis vajavad viivitamatult kirjutamist või värskendamist.

See disain muudab XFS-i eriti kasulikuks suurte failide ja salvestusruumi käsitlemisel. Maksimaalne faili suurus tollides praegune hetk on 9 eksabaiti ja üks köide võib olla kuni 18 eksabaiti. Failide koguarv ei ole piiratud. Teiste hulgas tugevused see failisüsteem:

Ajakirjandus. Logimise kasutamine metaandmete toimingute jaoks tagab XFS-i järjepidevuse isegi pärast krahhi või toitekadu.

Hilinenud eraldamine. XFS-is olevaid andmeid kohe ei kirjutata kõvaketast, kuid salvestatakse mõnda aega RAM-i, samal ajal kui vajalik arv andmeplokke lihtsalt reserveeritakse. Lõpuks võib selguda, et seda pole üldse vaja kirjutada. Seega optimeerib XFS kirjutamisjõudlust ja vähendab failide killustatust.

Eeljaotamine. XFS reserveerib kettaruumi enne andmeplokkide kirjutamist. See aitab vältida ka failide killustumist alates täielik fail kirjutatakse tõenäolisemalt kettale külgnevasse plokkide seeriasse.

Vähesed failid. Kui fail sisaldab nullandmete tükke, siis selle asemel, et eraldada neile kettaruumi, kirjutab süsteem ainult osa neid esindavatest metaandmetest. tühjad klotsid ja väldib seega ruumi raiskamist "nullidele".

Kettakvoodid. XFS toetab kettakvoote, mis võimaldavad kettaressursse tõhusalt hallata, piirates loodavate failide arvu teatud grupp kasutajad/kasutajad või kasutatud mälumaht.

Laiendatud atribuudid. Laiendatud atribuudid võimaldavad kasutajal lisada suvalisi metaandmeid (nime-väärtuse paarina) mis tahes failile või sisendile. Erinevalt tavalistest atribuutidest, mis on failisüsteemis rangelt määratletud, võivad need sisaldada mis tahes teavet, näiteks dokumendi autori või digitaalallkirja kohta.

Täiustatud sisend/väljund. Mitme jaotusrühma kasutamine võimaldab suurt kiirust paralleelsed toimingud I/O

Helitugevuse hetktõmmised. Snapshots võimaldab teil luua köite koopia teatud hetk aega ja vajadusel tagastada failisüsteem sellesse olekusse.

Internetis defragmentimine ja suuruse muutmine. Failisüsteemi võib installimise ja aktiveerimise ajal defragmentida või suurendada.

Algne varundamine/taastamine. XFS-il on sisseehitatud varukoopia ja taastamine, mida saab teha sisseehitatud utiliitide xfsdump ja xfsrestore abil. Veelgi enam, isegi failidel, mida mingil põhjusel ei varundatud, vastupidiselt levinud arvamusele, on andmete kadumise korral äärmiselt suur taastamise võimalus. Kuigi mõned eksperdid väidavad, et andmete kadu XFS-ist on täiesti taastumatu, on paljud andmete taastamise tööriistad, nagu UFS Explorer, Recovery Explorer ja Raise Data Recovery, selle ülesandega edukalt hakkama saanud juba aastaid.

Sellel failisüsteemil on aga ka mitmeid puudusi. Esiteks ei saa XFS-iga vormindatud partitsiooni kahandada, kuigi saate seda siiski teha varukoopia, looge uus väiksem failisüsteem ja seejärel taastage see. Teiseks ei ole XFS-il sisseehitatud andmete tihendamise meetodeid. Veelgi enam, failisüsteem ei kasuta kontrollsummad et tagada salvestatud kasutajaandmete terviklikkus ja tuvastada kõik mädad bitid võimalikult kiiresti, nii et mõned failid võivad vaikselt rikkuda ja kui see lõpuks välja tuleb, võib probleemi lahendamiseks olla liiga hilja ja sellega kaasneb tohutu andmekadu. vältimatu. Lisaks kasutab XFS metaandmete logimist, kuid ei muuda andmemuudatusi, nii et kui ootamatu seiskamine süsteemi, kaotate tõenäoliselt praegu avatud failide andmed. Samuti, kui teil on kahesüsteem Windowsi käivitamine/Linux, Windows ei saa XFS-vormingus partitsiooni lugeda ilma täiendavate tööriistadeta.

Et teada saada, kas teie ketas toetab XFS-i, kasutage failikäsku koos võtmega -s, mis näitab teavet failisüsteemi tüübi kohta.

Üldiselt, kuigi puudusi pole, on XFS üsna töökindel ja funktsioonirikas failisüsteem, mis paistab silma suure jõudlusega meediumide haldamisel. Kui teil on vaja salvestada ja juurde pääseda suured failid XFS on ilmselt parim.

Hiljuti, linux.conf.au 2012 konverentsil märkis XFS-i arendaja Dave Chinner, et ta usub XFS meelitab tulevikus rohkem kasutajaid. Tema aruanne käsitles nii skaleerimisega seotud probleemide lahendamist kui ka edasine töö failisüsteemi täiustamiseks. Kui tema sõnu uskuda, kuuleme sellest lähiaastatel ilmselt veel palju. XFS.
XFS sageli peetakse failisüsteemiks neile, kes failidega töötavad suured suurused. Dave'i sõnul tuleb see selle ülesandega suurepäraselt toime, lisaks XFS töötab traditsiooniliselt hästi rasked koormused. Kuid metaandmete kirjutamisel läheb olukord hullemaks. Salvestamise tugi suur kogus metaandmed on pikka aega nõrk koht selle failisüsteemi jaoks. Lühidalt öeldes kirjutatakse metaandmeid väga aeglaselt ja praktiliselt ei skaleerita isegi siis, kui need töötavad ühel CPU-l.
Kui aeglane? Dave esitas mitu slaidi, mis näitavad fs-marki võrdlusaluse tulemusi võrreldes ext4-ga. Tulemused XFS palju hullem (peaaegu kaks korda) isegi ühel CPU-l. Kui lõimede arv kasvab kaheksani, halveneb olukord veelgi, misjärel langeb järsult ka ext4 jõudlus. Töö jaoks, mis on seotud suur koormus I/O süsteemis, kus on vaja muuta suurt hulka metaandmeid (näitena toodi tarballi lahtipakkimine), näitas ext4 jõudlust 20–50 korda suuremat kui XFS. See viivitus on tõeliselt tõsine probleem.

Laisk metsaraie

Probleem on I/O logis: XFS tekitas metaandmete muutmiseks väga palju liiklust. Halvimatel juhtudel oli praktiliselt kogu I/O-liiklus logiandmed, mitte andmed, mida kasutaja üritas kettale kirjutada. Aastate jooksul tehtud katsed seda probleemi lahendada on hõlmanud ühte olulist salvestusalgoritmi muudatust ning palju muid olulisi optimeerimisi ja muudatusi. Ainus asi, mida ei nõutud, oli ketta andmevormingu muutmine, kuigi seda võib tulevikus vaja minna.
Suure hulga metaandmete muutmisega kaasnev stress võib lõpuks põhjustada sama kataloogiplokki muutmise lühikese aja jooksul mitu korda, kusjuures iga muudatus loob kirje, mis tuleb logisse salvestada. See on tohutu ajakirjaliikluse allikas. Selle probleemi lahendamise kontseptsioon on väga lihtne: lükake logi värskendamine edasi ja ühendage sama ploki muudatused üheks kirjeks. Tegelikult kulus selle idee skaleeritava teostuseni viimiseks mitu aastat rasket tööd, kuid nüüd see töötab. Laisk ajakirjandus failisüsteemi jaoks XFS toetab kerneli versioon 3.3.
Tegelikult laenati laisk ajakirjandustehnoloogia ext3 failisüsteemist, nii et selle toimimise algoritm on teada ja selle rakendamiseks kulub palju vähem aega. XFS kui see oleks nullist välja töötatud. Koos kiiruse eelistega tähendab see ka koodi mahu olulist vähenemist. Kui soovite selle tehnoloogia toimimist lähemalt uurida, leiate üksikasjad failist filesystems/xfs-delayed-logging.txt kerneli dokumentatsioonipuus.
Laisk metsaraie on suur muutus, kuid see pole ainus. Kiire viis ajakirjade ruumi reserveerimine on endiselt kuum teema XFS. Tänapäeval see blokeerimist ei nõua, samas kui aeglane meetod nõuab siiski selle punkti globaalset blokeerimist. Asünkroonse metaandmete kirjutamise kood põhjustas tõsise I/O killustatuse, vähendades oluliselt jõudlust. Nüüd on metaandmete kirjutamine viibinud ja need sorteeritakse enne kirjutamist. See tähendab, et Dave'i sõnul toimib failisüsteem I/O planeerijana. Kuid I/O planeerija töötab päringujärjekorras, mis on tavaliselt piiratud 128 kirjega, samas kui metaandmete edasilükatud järjekord XFS võib sisaldada tuhandeid kirjeid, nii et enne metaandmete edastamist I/O-süsteemi on mõttekas sorteerida failisüsteemis. " Aktiivsed elemendid"Aktiivsed logiüksused" on mehhanism, mis parandab jõudlust suurte sorteeritud logiüksuste loenditega töötamisel, kogudes muudatusi ja rakendades neid partiirežiim. Lisaks eemaldati vahetuslehelt vahemällu salvestatud metaandmed, kuna nende olemasolu põhjustaks taotlusi lehtede laadimiseks sobimatutel aegadel.

Failisüsteemide võrdlus

Kuidas XFS kas see skaleerub pärast kõiki muudatusi? Ühe või kahe lõimega töötades on see siiski pisut aeglasem kui ext4, kuid lõimede arvu kasvades kaheksani suureneb selle jõudlus lineaarselt, samal ajal kui ext4 halveneb ja btrfs halveneb veelgi. Tänane mastaapsus XFS piirdub virtuaalsete failisüsteemidega tegeleva kernelikihi blokeerimisega, mitte aga otseselt failisüsteemiga tegeleva koodi blokeerimisega. Kataloogide läbimine on nüüd kiirem isegi ühe lõimega ja veelgi kiirem kaheksa lõimega.
Ketta eraldamise skaleeritavus on praegu suurusjärgus kiirem kui ext4. See olukord muutub veidi, kui versioonis 3.2 võetakse kasutusele funktsioon "bigalloc", mis suurendab ext4 kettaruumi eraldamise skaleeritavust kahe suurusjärgu võrra, kui seda kasutatakse piisavalt. suur suurus blokk. Kahjuks suurendab see proportsionaalselt väikeste failide kettaruumi. Näiteks paigutada lähtekoodi tuumad Linux sel juhul on vaja 160 GB kettaruumi. Bigalloc ei ühildu eriti mõne muu ext4 funktsiooniga ja nõuab keerukat konfigureerimist. Dave’i sõnul kannatab ext4 arhitektuuriliste vigade all – kaheksakümnendatele olid tüüpilised asjad nagu bitmapsi kasutamine kettaruumi jälgimiseks. Seda lihtsalt ei saa skaleerida tõeliselt suurtele failisüsteemidele.
Kettaruumi eraldamine Btrfs-is on veelgi aeglasem kui ext4-s. Dave’i sõnul on probleemiks peamiselt vahemälu liigutamine vabale kettaruumile, mis kulutab liiga palju protsessori võimsust. Kuid see ei ole arhitektuuriline viga, nii et seda saab üsna lihtsalt parandada.

Linuxi failisüsteemide tulevik

Tänapäeval võib jõudluse ja skaleeritavusega seotud probleeme pidada lahendatuks. Pudelikael on nüüd VFS-kiht, nii et sellesse töövaldkonda tuleks suunata edasised jõupingutused. Kuid suurim väljakutse tulevikus on andmesalvestuse usaldusväärsus ja see võib nõuda olulisi muudatusi XFS-failisüsteemis.
Usaldusväärsus ei seisne ainult andmete mittekaotamises – me loodame seda XFS on juba üsna töökindel, probleem on seotud ka skaleeritavusega. Petabaidi failisüsteemi lahtiühendamine skannimise või andmete taastamise utiliidi käivitamiseks pole lihtsalt otstarbekas. Tulevikus on lihtsalt vaja võimaldada selliseid toiminguid teha töötavas failisüsteemis. See nõuab metaandmete käigupealt kontrollimiseks failisüsteemi sisseehitatud tugevat krahhi tuvastamise tööriista. Mõnel teisel failisüsteemil on sarnased mehhanismid, kuid Dave'i sõnul XFS Parem oleks sellist süsteemi rakendada andmesalvestusseadmete massiivide või rakenduste tasemel.
„Metaandmete valideerimine” tähendab metaandmete väljatöötamist, mis kaitsevad end salvestusseadme tasemel valesti suunatud kirjutamistaotluste eest. Kontrollsumma kontrollimisest ei piisa – see näitab vaid, et andmed on õigesti kirjutatud. Sellise kaitsega metaandmed võivad tuvastada valesse asukohta kirjutatud plokid ja aidata taastada failisüsteemi terviklikkust suuremate rikete korral. See võib samuti aidata lahendada teadaolev probleem reiserfs, mis tähendab, et failisüsteemi parandamise utiliit on segaduses vananenud metaandmete või failisüsteemi piltidelt leitud metaandmete tõttu.
Selliste metaandmete väljatöötamine nõuab palju muudatusi. Iga metaandmete plokk sisaldab failisüsteemi UUID-d, millesse see kuulub, samuti plokkide numbreid ja inode et failisüsteem saaks kindlaks teha, kas metaandmeid edastatakse õigest allikast. Samuti on olemas kontrollsummad rikutud metaandmete plokkide tuvastamiseks ja kohandatud identifikaator metaandmete seostamiseks oma sisendmooduli või kataloogiga. Jaotuspuu ümberpööramine võimaldab failisüsteemil kiiresti tuvastada, millisesse faili mis tahes plokk kuulub.
Muidugi praegune formaat XFS ei salvesta kõiki neid lisaandmeid, seega tuleb neid muuta. Dave’i sõnul pole aga plaanis ühtegi ülal pidada tagasiühilduv praeguse failisüsteemi vorminguga. Seda tehakse selleks, et anda arendajatele täielik vabadus luua uus failisüsteemi vorming, mida kasutatakse veel palju aastaid. Lisaks ülalkirjeldatud funktsioonide lisamisele on arendajatel kavas lisada kataloogistruktuuris ruumi d_type jaoks, NFSv4 versiooniloendurid, inode loomise aeg ja ilmselt palju muud. Suurendatakse ka maksimaalset kataloogi suurust, mis praegu on vaid 32 GB.
Kui kõik need funktsioonid on rakendatud, tekivad uued võimalused: failisüsteemi riknemise proaktiivne tuvastamine, blokeeritud plokkide lokaliseerimine ja asendamine, samuti täiustatud failisüsteemi vigade parandamine. See tähendab, nagu Dave ütles, seda XFS jääb parimaks failisüsteemiks töötamiseks suured mahud andmeid Linuxi all aja jooksul.
Millised on selle kõige tagajärjed btrfsi vaatenurgast? Dave'i sõnul pole btrfs selgelt töötamiseks optimeeritud suur hulk metaandmed – saadaval tõsiseid probleeme skaleeritavusega. Seda võib oodata failisüsteemilt selle arendamise algstaadiumis. Nõutakse teatud aeg nende probleemide lahendamiseks ja mõned neist võivad osutuda lahendamatuks. Teisalt on btrfs-is andmesalvestuse töökindlus suurepärane ja lähiaastatel saab seda selles mahus kasutada.
Ext4 seevastu kannatab mastaapsuse probleemide tõttu, mis on tingitud infrastruktuuri vigadest. Igatahes Dave’i antud testitulemuste järgi pole see kõige kiirem. Selle arhitektuuri auväärne vanus on kõnekas, kuigi plaanitakse selle töökindlust parandada. Ext4 võitleb lähitulevikus konkurentidega samal tasemel püsimise nimel.
Oma kõne lõpus tõstatas Dave veel mõned küsimused. Tema sõnul vahetab btrfs oma eeliste tõttu peagi välja ext4 vaikefailisüsteemina paljudes distributsioonides. Samal ajal on ext4 halvem XFS enamikus tööoperatsioonides, sealhulgas nendes, kus see on traditsiooniliselt tugev olnud. Skaleeritavuse probleem ilmneb juba kell väikesed serverid. Pealegi pole see nii stabiilne, kui kasutajad arvavad. Lõpus küsis ta: "Miks me ikka veel ext4 kasutame?"
Võiks eeldada, et ext4 arendajatel on sellele küsimusele hea vastus, kuid kahjuks polnud ruumis ühtegi neist. Seega tundub, et seda arutelu tuleb mujal jätkata. Teda saab olema huvitav kuulata.