Milyen compressed rw filesystem?

Fórumok

Sziasztok!

Adott egy alkalmazás, ami jól tömöríthető (kb. 80-90%) fileokat ír folyamatosan a diskre. (visszaolvasás csak restart esetén van)
Az alkalmazás kódja nem változtatható, az oprendszer SLES 10 SP3, de nemsokára újabbra lesz cserélve.
A CPU oldal erős (8 core * 2.2Ghz), viszont nagyon durva IO limit van.

Van egy teszt rendszerem, ahol szeretném az alkalmazás alatt a filerendszert kicserélni egy olyanra, ami transzparens tömörítést biztosít, hogy megnézzem, hogy mennyit nyerek vele, és főleg, hogy mennyire stabil egy ilyen rendszer.

Amiket eddig találtam:
-reiser4 (patchelt kernellel)
-btrfs (SLES 11 SP2)
-zfs (Solaris / BSD only)
-e2compr (csak hogy legyen egy oldtimer is)

A user space módszereket egyelőre kerülném, ahogy néztem, ott az egyetlen használható megoldás kb. a fusecompress.

A kérdésem az lenne, hogy szerintetek érdemes-e ezzel próbálkozni, és főleg, hogy milyen tapasztalataitok vannak.
Jelenleg a btrfs lenne a legszimpatikusabb, de az fsck hiánya kicsit elriasztott.

Előre is köszönöm a segítséget. (+az építő jellegű kritikus trollkodást is :))

Hozzászólások

En ugy emlekszem, a lessfs is tudja a tomoritest es talan az opendedup is.

zfs: nem linux only van fuse-os megoldas linux-on (par eve meg nem volt igazan stabil, azota nem tudom) es van nativ implementacio is.

A BTRFS nalam meg nem mukodik olyan igazan rock solid modon, secondary backup szervert biztam csak ra.

Kerdezni elfelejtettel. Vagy csak annyi a kerdes, h melyiket?
ZFS linux/solaris/fbsd-k kozul azon, amelyikhez ertesz.

tompos

Egyre több helyen használok btrfst, pl. az asztali gépem rootja, és néhány adat partíciója is az. A fontos dolgokról van backup, de eddig elég jók a tapasztalatok. A legdurvább hiba amivel találkoztam eddig, egy backup fs sérült meg(??) és subvolume törlésétől segfaultolt a 3.2.x kernel több alverziója is. Nem tudtam tovább őrizgetni a backupját, úgyhogy nem tudom a 3.4 már helyrerakta volna-e. De adat itt sem veszett el, és sysresc es 3.0 kernellel a subvolume is törölhető volt, tehát valószínűleg valami kernel hiba lehetett. Már sose tudjuk meg. A 3.4ben nagyon sokat fejlesztettek stabilitáson is, passz, más hibám még nem volt. fsck meg van már, meg recovery is, de még nem teszteltem őket sérült filerendszeren. Amit fentebb írtam, arra az fsck írt egykét hibát (kb. ilyen lost+found gyanús dolognak tűnt), de fixálni meg se próbáltam, és recovery nem kellett, mert minden olvasható volt.

Ha van backupod, akkor szerintem nem megbízhatatlan, winyó hibánál meg másik fs se fog többet segíteni. A tömörítést nehéz megjósolni, default zlib et használ, váalsztható még az lzo is, de az nem tömörít olyan jól, viszont elvileg gyorsabb. Gyakorlatilag nekem tökmind1, mert nem a proci a szűk keresztmetszet, úgyhogy inkább tömörítsen.

Nem, mert a megbizhatosag mindig szubjektiv. Csak ugy tudod merni, hogy ki mit mer rabizni egy adott dologra. Azt nem tudod elore, hogy mennyi gond lesz vele, mert ha tudnad akkor javitanad. Azonban tudod merlegelni a kockazatokat es azok illetve a meglevo tapasztalat alapjan el tudod donteni, hogy eleg megbizhato-e valami. Ez viszont szubjektiv es foleg azon alapul, hogy mas mennyire bizik mar benne.

Igy mar picit ertelmesebb, amit irtal.
De ettol fuggetlenul a backupnak mi koze a megbizhatosaghoz?
Mindenesetre amit irtal, tovabbra sem a megbizhatosag definicioja, hanem a tesztelesre alkalmas jelzo illeti.

En is hasznalom. Szerencsetlen attol osszedolt, h nem volt hely es nem tudott subvolume-ot letrehozni.

Adat vesztes nem volt, attol meg a funkciojat nem latta el, igy csak 1 ponttal kap tobbet a hig szarnal.

Vagy te tenyleg stabilnak nyilvanitod ennyi alapjan?

tompos

ui.: ezt amugy hogyan kell erteni?
"egyszer volt vele gondom'de egy bizonyos kernel szeria volt erintet"
Ha van 1 kernel amiben eppen nem borul meg, akkor onnantol stabil? Rabiznad a tokeidet? Sok sikert hozza:)

Nem régóta használom. Nagyon fejlesztik, szoktam nézni a patcheket, tehát optimista vagyok. Mivel óvatos is, ezért csak olyan helyeken használom, ami backupolva van (itt jön a képbe a backup). Attól, hogy óvatosan állok hozzá, még lehet megbízható. Most eltelnek hónapok, és fokozatosan egyre több dolgot fogok rárakni, ahogy egyre többet teszteltem.

Ertem en es hasonlot csinalok en is, meg meg sokan masok. Azt szeretnem csak tisztaba rakni, hogy felelotlenseg kijelenteni vmirol, h megbizhato, ha egyebkent fogalmad nincs.
Egy FS megbizhatonak akkor tekintheto(*), ha evekig critical bugok nelkuliek a kiadasok.
Amit te irsz, arra illik mondjuk a biztato jelzo, vagy az igeretes. Ez igy korrekt.

tompos

ui.: Mondtam vmit hasbol, de gondolom vhol ebben az iranyban van a lenyeg.

Rossz winyokat teszteltem hotswap,hivatalosan nem hotswapos gepben,mikozben masoltam ra egy masik winyirol.tobbszor lefagyott,de nem lett semmi baja.itthoni gepem szunetmentese elromlott,root meg home es tobb tera adat,egy reszuk irva olvasva.nem lett gond.kb eddig ennyi.direkt meg nem akartam kiakasztani.

ZFS :)

Kiválóan működik a default tömörítése. Igaz, Solaris (leginkább) kell miatta.

--
Java apps are nothing more than sophisticated XML-to-exception converters.

btrfs +1

Linuxok jövő alap fájlrendszere.
Nem tudom a tömörítése milyen, nincs tapasztalat ez ügyben.
Viszont hosszú távra jó választás, mert óriási support van mögötte.

szerk:

A reiser pedig zsákutca mint tudjuk. Az Új meg már nem lesz a régi :D

1. jovo, lesz: tenyleg nem erted, mi a kulonbseg a jovo es a jelen ido kozott, vagy csak adod a hujet vmi okbol?

2. Nem az a kerdes, h ki fejleszti, hanem h ki supportalja? Szuper, h az Oracle fejleszti, de ezzel konkretan semmit nem er az enduser, nem szamitva ha Oracle Linux-ot hasznal es vett hozza kulon supportot, de ilyen extra kitetelekrol nem volt szo.

tompos

Fura egy alak vagy...

Sajnálom, ha félreértettél.
A btrfs itt van. Nem egy jövőbeli FS. Használatos, stabil. Elég nagy cégek használják ezt, akik nem torrent filmeket tárolnak rajta...
Azért mondtam, hogy a jövő, mert rengeteg feature-e van, és ez lesz az extended-ek után az egyik legnépszerűbb FS.
Csak jót halottam róla és tapasztaltam vele.

Jha és kérlek tompos, hogy ne csak kritizálj ha nem értesz egyet (jogod van hozzá), hanem kicsit támaszd alá egyet nem értésedet alapját. (Köszi)

Én felraktam a btrfst otthoni gépemre, Fedora 16-tal (már a 17-tel), érzésre lassabb volt, mint az előző ext4 (bár csak 1 giga RAM volt a gépben, azóta ez bővült), viszont el még nem szállt ez alatt a fél év alatt.

subs

Én most tervezem a btrfs kipróbálást.
Egyenlőre egy Arch doboz lesz az iroda sarkában ami backupolja a helyi szerver adatait. Majd meglátom milyen.
Azért Arch mert gyorsan frissül a kernel.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # N210/Arch

Szia!

Nem olvastam el minden hozzászólást, így nem tudom lehet olyan írok, amit már más is írt.
Ha csak egyetlen ilyen program van, akkor nem lehet tökéletes megoldás egy szkript mondjuk cronba téve, ami szépen letömörítgeti neked a cuccot? Persze tényleg lehet nem egy userspace megoldás a legszebb, de amit leírtál abból nekem úgy tűnik, hogy az a legcélravezetőbb.

FathoM

tovább gondolva ezt a vakvágányt :)

v1. a file-okat nem írod disk-re, hanem átpipe-olod egy valami zip-en
v2. tempfs-re írsz, memoárban tömoríted, és onnan írod ki

:)

ps.: mert egyébként az a baj, hogy a btrfs szerintem még nem teljesen kiforrott, mert ha az lenne akkor az lenne a megoldás.