A Next3 fájlrendszer - ext3 snapshotting képességekkel

Fájlrendszer, NAS, storage

Noha az ext3 fájlrendszer kipróbált és bevált, számos olyan szolgáltatást mellőz, amelyet napjaink felhasználói szívesen látnának. Valahol a hiányzó funkciók képzeletbeli listájának tetején foglal helyet a snapshotting képesség, vagyis az a szolgáltatás, amely lehetővé teszi a fájlrendszer állapotának egy adott pillanatban való gyors "elkapását", egy pillanatfelvétel készítését. Ugyan van lehetőség az LVM snapshotting szolgáltatásának ext3 fájlrendszerrel együtt való használatára, azonban a LVM-en keresztül készített snapshot-oknak számos korlátja van. A Next3 fájlrendszer egy egyszerűbb megközelítést használ az ext3 + snapshot témakörben: közvetlenül az ext3 fájlrendszerbe implementálja a snapshotting képességet.

A Next3 fájlrendszert a CTERA Networks fejlesztette ki. A megoldás nem csak kód formájában létezik, hanem forgalomban levő kereskedelmi termék része is. A vállalat CTERA C200 adattároló eszközeiben dolgozik.

A Next3 fejlesztői a kódot publikálták, feltolták a Sourceforge-ra és javaslatot tettek arra, hogy a kernelfejlesztők olvasszák be a mainline kernelbe. A Next3 licence GPL.

A fájlrendszer számos szolgáltatást ígér, jellemzővel bír:

  • vissza- és előrefelé kompatibilis az ext3 fájlrendszerrel
  • inkrementális, kötetszintű, csak olvasható snapshotokat kínál
  • a snapshotok törlésével automatikusan felszabadul a lemezterület
  • megtartja az ext3 stabilitását, beleértve a naplózó (journaling) és fsck képességeket
  • minimális teljesítménybeli overhead-del rendelkezik (átlagos felhasználást véve)
  • nincs felső korlátja sem a snaphotok számának, sem azok méretének

Vagyis, a Next3 egy egyszerű snapshotolási képességet valósít meg az ismert ext3 fájlrendszerrel oly módon, hogy (nagyrészt) kompatibilis marad ext3 lemezformátumával. Az általa kínált szolgáltatás hasznosnak látszik, de ennek ellenére úgy tűnik, hogy az eredeti fejlesztők által tervezettnél hosszabb utat kell megtennie ahhoz, hogy a mainline kernel része lehessen.

A Next3 egy új fájlrendszertípus, nem csak egy bővítmény az ext3-hoz. Köszönhetően annak, hogy a lemezformátuma csak minimálisan tér el az ext3-étól, a meglevő, ext3-hoz használható kódokkal felcsatolható.

A Next3 fejlesztők a fájlrendszert nem az ext3 kibővítésével akarnák a mainline kernel részévé tenni, hanem önálló fájlrendszerként. Így nem kellene az ext3-hoz hozzányúlni. Amir Goldstein, a Next3 fejlesztője egy relatíve gyors áttekintést kért a kernelfejlesztőktől, mert próbálja véglegesíteni a fájlrendszer lemezformátumának bizonyos részeit. Azonban a Ted Ts'o-tól érkező válasz feltehetően nem az volt, amire várt.

Ted átfutotta patcheket és azt tapasztalta, hogy a Next3 olyan mezőket használ, amelyeket az ext4 is, így egyes helyeken átfedések vannak. Elmondta, hogy az ext4 az a fájlrendszer, ahol az új fejlesztések folynak, így az ext3-hoz történő fejlesztéseket nem fogják feltehetően kitörő örömmel fogadni. Az e2fsprogs (amivel az ext2/ext3/ext4 fájlrendszerek kezelhetők) kérdéskör is felmerül és Ted nem akar e2fsprogs csomagot karbantartani külön-külön az ext* fájlrendszerekhez és a Next3-hoz.

A Red Hat-es Ric Wheeler sem tartja szerencsésnek az ext3 fájlrendszerhez való fejlesztését annak fényében, hogy az LVM-mel van lehetőség ext3 snaphotolásra, illetve, hogy "már a sarkon van" a btrfs, ami már tartalmazza ezt a funkciót.

Szóval az lenne az üdvözlendő megoldás, ha a Next3-at az ext4-hez igazítanák a fejlesztők. Amir válaszában elmondta, hogy noha a patchek ext4-hez portolása a fejlesztők todo listáján van, nem olyan egyszerű a dolog.

A thread itt kezdődik. További részletek az LWN (egyelőre még fizetős) cikkében.

( sunmao v | 2010. 05. 16., v – 14:15 )

Ha jól értem ez akkor most egy új módja lehetne a backupolásnak? Már régóta tervezem azt, hogy a rendszeremet újrahúzom és mikor úgy érzem, hogy az alap dolgok fent vannak akkor arról csinálok egy jó kis snapshotot, mert mire belövök mindent ez alatt a rendszer alatt az nem két perc. Sajnos mikor feltettem akkor erre még nem gondoltam csak az volt a cél, hogy menjen, farigcsáltam fejlesztgettem, sok mindent kipróbáltam, letöröltem, újrahúztam rajta. Most van egy aránylag stabil rendszerem, eddig is gondolkoztam azon, hogy hogy lehetne szépen egy az egybe az egész rendszert lementeni, illetve ezt mások hogy szokták megoldani (esetleg dd-vel?). De akkor elvileg ez ehhez nyújtana megoldást. Például van egy snaposhotom egy full-os rendszerről elcseszek valamit, akkor vinyó ledúr ext3-ra megformáz és a snapshotból backup, így valahogy? Mindent esetre, ha bekerülne a mainline kernel-be biztos egyből bele fordítanám. Javítsatok ki ha tévedek, de ez most a home usereket célozza inkább nemde? Mivel cégeknél ált. nem ext3-at használnak, értsd: nagyobb vállalati környezetben valami "jobb" fs-t.

Megnyugtatlak, hogy ha linux-ról van szó, akkor a nagy nagy cégek is ext3-at használnak. Egyelőre ez a legstabilabb. A snapshot-nak pedig nagyvállalati környezetben is van létjogosultsága. Persze egy Oracle-t nem fogsz snapshot-olni, de userek HOME-ját vagy webserver vhost-jait lehet.

Aműgy meg a legegyszerűbb megoldás a farigcsálásra, hogy a HOME-od külön oartíción van és néha csinálsz egy "tar xvfz"-t a szükséges dolgokról. :)

Lehet nem jött le a postomból de nem Ubuntut használok... :) Nem a home-al van a legnagyobb probléma, mert a a fontos adataimat egy univerzalisabb helyen tárolom, amely elérhető windowsról és linuxról is, a home-ba csak átmeneti cuccok vannak.

Én már kifaragtam amit akartam, de nem biztos hogy még egyszer lesz időm végig járni ezt a rögös utat... :D Viszont arra az esetre ha lenne mégis rá időm jól jönne a kész rendszerről egy mentés, amit bármikor visszatölthetek. Az előző post burkoltan egy kérdés is lett volna, ki mivel menti le a "kész" rendszert, de én itt a mintésre mint igazi mentésre, gondolok tehát ha a kész rendszerem 20Gb akkor 20Gb-t ment le és nem csak beállításokat tárol hanem konkrétan a vinyó tartalmát, erre jött a kérdés ha ilyen deep copy val (dd-vel) lementem egy az egybe az egészet az egy jó megoldás? Illetve lehet-e ezt valamilyen tömörített formában csinálni, a kérdésem továbbra is fenn áll, illetve hogy ez a Next3 erre lenne-e megoldás?

"A snapshot-nak pedig nagyvállalati környezetben is van létjogosultsága."

Olyannyira, hogy ott tizenéve használják is aktívan.

"Persze egy Oracle-t nem fogsz snapshot-olni"

Meglepődnél.... bevett módja az Oracle file szintű mentésének, hogy snapshotból mentik. Így max. csak a snapshot idejére kell leállítani az adatbázist, a snapshotból aztán konzisztens mentést lehet csinálni.

Mondjuk álltalában storage szintű snapshotot használnak, de láttam már zfs snapshot alapon működő Oracle mentést is.

dd, ghost4linux, de főleg

partimage vagy clonezilla (ez utóbbi egy disztribúció)

---
Ami a windowsban szarrágás, az linuxban hegesztés.
Ha megszeretted a windowst, tanuld meg használni!
A linux igenis felhasználó-, és NEM idiótabarát.
A linuxot mi irányítjuk, a windows minket irányít.

Inkább csak sunmao burkolt backup kérdésére próbáltam válaszolni.

Egyébként ki tudja miért miért nem, windows alatt pl. Symantec _feltelepített_ backup cuccai külön shadow service szolgáltatást izzítanak be.

---
Ami a windowsban szarrágás, az linuxban hegesztés.
Ha megszeretted a windowst, tanuld meg használni!
A linux igenis felhasználó-, és NEM idiótabarát.
A linuxot mi irányítjuk, a windows minket irányít.

Ha jól értem ez akkor most egy új módja lehetne a backupolásnak?
Snapshot != backup. A snapshot kell ahhoz, hogy konzisztens backupot tudj csinálni egy működő rendszerről, de a snapshot önmagában még nem véd egy csomó minden pl hardver meghibásodása ellen.

Amit te akarsz az egyébként LVM snapshottal is megoldható a fájlrendszer szintje alatt.

A fő különbség, hogy blokkos eszköz szintjén csinált snapshot előre fixen allokált méretű kötetre dolgozhat, tehát nem túl dinamikus. Valamint a fájlrendszer által elhagyott szemeteket is teljesen feleslegesen copy-on-write-tal védi, míg a fájlrendszer szintjén csinált snapshot csak a hasznos adattal foglalkozik. A fájlrendszer egyéb belső magánélete, mint pl blokkok áthelyezése, scrubbing, defrag, is feleslegesen növeli a snapshotban másolt adatok méretét, fájlrendszer szintjén viszont ez korlátozódik a fájlok tényleges tartalmára, függetlenül attól, hogy a fájlrendszer mit mikor rendez át. Aztán lehetőség van a fájlrendszer szintjén csak egyes fájlokra vonatkozó szelektív snapshotot is csinálni, míg LVM-mel mindig az egész blokkos eszközt snapshotolod, ha kell, ha nem.

Ez nem jelenti azt, hogy az LVM snapshot elavult lenne, megvan mindekettőnek a maga felhasználási területe.
---
Internet Memetikai Tanszék

Pl, ha SAN-hoz ajánlasz ki blokkos eszközt és a kiszolgáló gépről semmi belelátásod nincs a blokkos eszközön belül lévő fájlrendszerbe. ESX szervernél a VMFS tipikusan ez az eset, de ugyanez van iSCSI-ról Windows-nak adott NTFS volume-mal is. Az utóbbiba a storage szerveren nem tudsz működés közben belenézni még ntfs-3g-vel sem, de még leállított állapotban is küzdés felmountolni, pláne, ha dynamic disk réteg is van közben. Hasonló a helyzet, ha adatbázis van közvetlenül a volume-ra téve.

Persze mindegyikre lehet mondani, hogy alkalmazás szinten/windows szintjén kéne backupolni és akkor nem is kell sosem snapshotot csinálni a storage szerveren, de a gyakrolatban azért mégiscsak szokott kelleni. Nem azonos idő visszaállni egy backupból, ha boot blockkal és mindennel együtt a teljes gép diszkje megvan image-ben illetve ha csak az egyes alkalmazások backupja van meg, amiket újra föl kell húzni, mielőtt nekiállhatsz a visszatöltésnek. Van amikor ez utóbbi célravezetőbb. Pl konkrétan, ha egy annyira dinamikusan váltózó infrastruktúra van, hogy egyszerűen nem éri meg külön-külön gépenként összelőni a backupolást, viszont a folytonos homokozás miatt kell a visszaállás gyakran (értsd: a lustaság nagy úr, még akkor is, ha a másik megoldás erőforrás szempontból akár hatékonyabb is lehetne).
---
Internet Memetikai Tanszék

Na egy pillanat, te kevered a szezont a fazonnal! Én nem beszéltem konkrét implementációkról én a két megközelítést hasonlítottam össze. A két megközelítés közötti eltérés annyi, hogy a snapshotolt adatszerkezetbe belelátsz-e és ennek megfelelő finom felbontású snapshotot csinálsz-e, vagy csak simán egy blob-ként kezeled és ennek megfelelően egy durva felbontású, blokk szintű snapshotot csinálsz. Ha a ZFS-t használod volume managernek, és efölé raksz egy másik fájlrendszert/adatbázist/kisnyuszit, akkor éppenhogy a másodikat csinálod, mert a ZFS szempontjából az egész csak egy nagy átlátszatlan blob lesz. Tehát pontosan ugyanazok a hátrányok meglesznek, mintha egy Linux LVM (vagy AIX LVM, Windows Dinamic Disks, stb)-t használnál.

Ettől még persze jó dolog, hogy konvergálnak a volume managerek és a fájlrendszerek, de csodát azért nem tesznek.
---
Internet Memetikai Tanszék

> a ZFS szempontjából az egész csak egy nagy átlátszatlan blob lesz

Tényleg csak egy ártatlan javaslat, egy kósza gondolat, egy apró sugallat, avagy egy haszontalan jótanács: mi lenne, ha a fogalom nélküli válaszokat ezentúl hanyagolnánk?

NAME USED AVAIL REFER MOUNTPOINT
rpool/testvol 136M 177G 7.57M -
rpool/testvol@empty 15K - 16K -
rpool/testvol@newfs 0 - 7.57M -

(gy.k.: a newfs utáni snapshot helyfoglalása nem "blob-like" 136M, hanem csak 7.57M)

[ Like ]

Tényleg csak egy ártatlan javaslat, egy kósza gondolat, egy apró sugallat, avagy egy haszontalan jótanács: mi lenne, ha a fogalom nélküli válaszokat ezentúl hanyagolnánk?
Hmm... arra már nem kérhetlek, hogy ennek szellemében töröld a saját hozzászólásodat.

(gy.k.: a newfs utáni snapshot helyfoglalása nem "blob-like" 136M, hanem csak 7.57M)
Ugye tudod, hogy ezzel egy nagyon magas labdát adtál fel?! Ha igen, akkor ne is olvasd tovább, már nyilván leesett neked is és csak idegesíteni fog, hogy egy evidens dolgot magyarázok el neked.
Ez ugyanis egy nagyon szerencsétlen hozzászólás volt, ebből az derült ki, hogy te vagy az akinek téves fogalma van arról, hogy mit jelent az, hogy snapshot. Megmutatom...

Ezt magyarázd meg! Ebből azért egy kicsit több látszik, mint a te általad bemásolt 1db zfs list kimenetből. Minden lépést nézd meg jól, láthatod, hogy nem csalok: 


[xmi@mizar:~ ] sudo lvcreate -n TestVol -L 136M RootVG
  Logical volume "TestVol" created

[xmi@mizar:~ ] sudo lvs
  LV                 VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  HomeVol            RootVG -wi-ao  32.00g                                      
  RootVol            RootVG -wi-ao  16.00g                                      
  StoreVol           RootVG -wi-ao 272.00g                                      
  TestVol            RootVG -wi-a- 136.00m                                      
  VirtualMachinesVol RootVG -wi-ao 144.00g  

[xmi@mizar:~ ] sudo lvcreate -s -n TestSnap -L 136M RootVG/TestVol
  Logical volume "TestSnap" created

[xmi@mizar:~ ] sudo lvs
  LV                 VG     Attr   LSize   Origin  Snap%  Move Log Copy%  Convert
  HomeVol            RootVG -wi-ao  32.00g                                       
  RootVol            RootVG -wi-ao  16.00g                                       
  StoreVol           RootVG -wi-ao 272.00g                                       
  TestSnap           RootVG swi-a- 136.00m TestVol   0.01                        
  TestVol            RootVG owi-a- 136.00m                                       
  VirtualMachinesVol RootVG -wi-ao 144.00g     
                                  
[xmi@mizar:~ ] sudo mkfs.ext3 /dev/mapper/RootVG-TestVol
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
34816 inodes, 139264 blocks
6963 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
17 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks: 
	8193, 24577, 40961, 57345, 73729

Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

[xmi@mizar:~ ] sudo lvs
  LV                 VG     Attr   LSize   Origin  Snap%  Move Log Copy%  Convert
  HomeVol            RootVG -wi-ao  32.00g                                       
  RootVol            RootVG -wi-ao  16.00g                                       
  StoreVol           RootVG -wi-ao 272.00g                                       
  TestSnap           RootVG swi-a- 136.00m TestVol   6.43                        
  TestVol            RootVG owi-a- 136.00m                                       
  VirtualMachinesVol RootVG -wi-ao 144.00g

Jéé az mkfs után a snapshotból csak 6.43%-ot használ ki! Mennyi is ez, lássuk csak: 8.74MB, a 136MB helyett. Pedig nincs itt semmi ZFS, ez nem fájlrendszer szintű snapshot, ez egy vegytiszta volume szintű snapshot. Találd ki, hogy ez miért lehetséges, akkor utána sokkal jobban érteni fogod az én korábbi hozzászólásaimat is. Igen a ZFS-nek van egy rakás kellemes tulajdonsága, amiben jobb más megoldásoknál. Neked sikerült megtalálni azt az egyet, amiben azonos a többi snapshot megoldással és ezt tévesen a fájlrendszer szintű snapshot-kezelésnek tulajdonítod. Én részemről ezt a threadet befejeztem, szerintem innentől már magad is elboldogulsz.
---
Internet Memetikai Tanszék

Én egy szóval sem mondtam, hogy snapshot == backup. Az hogy egy új módja lehet a backupolásnak kb azt jelenti, hogy: ha csinálsz egy snapshotot és azt utána elteszed biztonságos helyre akkor ergo backupolsz, de javíts ki ha tévedek.

Ezen felül azt sem mondtam egy szóval se, hogy én dd-vel backupolok, ezt annak üzenem aki nekem esett hogy a dd nem backupolásra való.

Feltettem egy kérdést amire részben kaptam választ. Ha a te szavaidat jól értelmezem akkor a dd minden szemetet lemásol ami azért egy frissen telepített rendszernél nem olyan nagy probléma, egy használatban lévőnél már inkább. Akkor a Next3 az gondolom fs szintjén csinálná a snapshotot. De addig is amíg erre nincs lehetőség akkor LVM-et kellene használni, kaphatok némi útmutatást arra, hogy mégis hogyan valósítom meg a snapshot készítésest?

Feltetted a kérdést, hogy a dd-vel... satöbbi. Én meg válaszoltam, hogy a dd nem mentőeszköz - és azt is hozzátettem, hogy miért nem az. Ha "nekedesésnek" tűnt, akkor bocs, nem annak szántam.
A dd valóban mindent hűen lemásol - pontosabban bitről bitre beolvassa, és a paraméterezésének megfelelően akár konvertálva kiírja. Nem az a gond, hogy az "üres" területet is másolja, hanem az, hogy az output nem hordozható, abból egy adott állományt visszanyerni csak ott lehet, ahol az adott fájlt lehet eszközként kezelni (loopback mount), nem képes inkrementális, részleges mentésre, ésatöbbi.

Otthoni felhasználás esetén nincs sok értelme a snapshot alapján történő backupnak. Mentéseknél ugyanis leginkább arra jó a snapshot, hogy egy alkalmazás/adatbázis/file szervert konzisztensen lehessen menteni minimális szolgáltatásleállással. Otthon elég ritkán üzemel 0-24 kihasználtsággal gép.

Arra jó lehet otthoni felhasználás esetén is, hogy a véletlen törlés miatti adatvesztésd elkerüld, illetve upgrade/patch/szoftvertelepítés előtt visszaállítási pontot csinálj a rendszerben.

Ha a te szavaidat jól értelmezem akkor a dd minden szemetet lemásol ami azért egy frissen telepített rendszernél nem olyan nagy probléma, egy használatban lévőnél már inkább

ha jól értem, akkor Te rosszul érted, ha a mentendő part. 10 GB, a dd-s "mentés" akkor is 10 GB-ot fog lementeni egy fájlba, ha tök üres a part., ha friss a rendszer, és ha 10 éve telepítetted is, és full televan...
10 GB-tól csak akkor lesz kisebb, ha röptében tömöríted

--
by Mikul@s