[megoldva] Btrfs tömörítés - felvilágosítanátok?

Naplózó filerendszerek (journaling)

Sziasztok!

Szóval mind a rendszer, mint a /home partícióm ext4 és nincs velük semmi gond. Viszont egy HUP-os ajánlás alapján a torrent partíciómon bevállaltam a btrfs-t, mivel állítólag erre a célra elég jó. (egyebek mellet) Valóban, kifogástalanul működik és sosem volt bajom a teljesítménnyel. Néha ráengedek egy kis online defragot is, az is tök jól működik.

Na most olvastam, hogy a btrfs képes tömörítésre. Gondolom ez hasonló, mint az NTFS-féle tömörítés.

Viszont kérdéseim vannak ezzel kapcsolatban.
● Mennyire érezhető ez az írási/olvasási teljesítményt tekintve?
● Azt értem, hogy a partíción tömörítve vannak. De ha átmásolom/átrakom máshová, akkor ott is tömörítve lesznek, vagy ez csak a partíción való tárolásra vonatkozik?
● Mennyire hat ki negatívan a teljesítményre?
● Otthoni felhasználáshoz érdemes bekapcsolni? Nyernék vele annyi helyet, hogy megérje?

Ha számít, a konfig ez:
Linux Mint 17 x86_64 /w Cinnamon
ASUS M2N
AMD Athlon64 X2 6400+ @ 3.2GHz
2x2GB DDR2-800MHz CL5
GeForce GT610
WD10EZEX-00BN5A0 a torrentes diszkem

  • 3500 megtekintés

( ncc1701 | 2014. 10. 28., k – 11:28 )

Ha torrentezel, akkor gondolom filmek, zenék, esetleg programok. Mivel a médiák eleve tömörített formátumok (mkv, avi, mp3, flac), amik eleve be vannak tömörítve sokszor, ezért én rohadtul meglepődnék, ha akár 1%-ot is tudna rajta tömöríteni egy file rendszer.
Innentől kezdve a kérdés eléggé okafogyott. :)

( uid_6201 v | 2014. 10. 28., k – 11:32 )

compress(-force)=lzo - ezt ajánlják SSD-hez és nem veszel észre lassulást
compress(-force)=zlib - ez több számítást igényel, de mai procival forgótányéros háttértár esetén nem számottevő a lassulás.

Viszont:
- se jpeg fotókat
- se filmeket
ne akarj tömöríteni. Nem fog sikerülni ezekkel a veszteségmentes tömörítőkkel. Azt csak a film illetve fotó veszteséges átkódolásával tudod megoldani.

Még ez sem jó példa. A libreoffice ugyanis xml+kép egyvelegét hagyományos zip-pel tömöríti. Ezt a zip-et szintén nem tudod tovább nyomni. Bezzeg ha ki zipeled és zip helyett hatékonyabbat (tar.xz) használsz ... de az másik téma.

Próbáld meg gzip-pel vagy xz-vel tömöríteni és rájössz, hogy nem lesz kisebb.

Amire hatékony: word 6.0 doc xls és ppt formátum, text, html, db fájlok, log fájlok. Gyakorlatilag olyan állományokra, amik gzip-elve sokkal kisebb helyet foglal el.

Igen. Irodai teszt szerveren anno próbáltam, igaz, a zfs tömörítését, valami 5-10% közötti értékre emlékszem, de itt sok doksi van. Deduplikációval együtt jó lett volna, de mivel nem volt a gépben 64G memória, és igazából anno még nagyon experimentál volt, ezért maradt az ext4.

(Nálunk ms offfisz van használva, azt lehet tömöríteni, viszont sok az image file is, azokat meg nem lehet.)

( Turion | 2014. 10. 28., k – 11:47 )

Köszi a válaszokat. Tehát akkor ez a fícsör nem nekem van, világos. :)
Ma is tanultam valamit.

Linux Mint 17 Cinnamon 64-bit

( fathom | 2014. 10. 31., p – 16:17 )

Sziasztok!

Én kíváncsi lennék egy tényleges usecase-re is, ha valaki tud ilyen ossza meg.

Emlegetett valaki ősrégi tömörítetlen formátumokat, de ilyen azért már csak nagyon kevés helyen használnak és nem gondolom, hogy olyan rengeteg lenne belőle, hogy ezért fs szintű tömörítést kéne alkalmazni (amúgy már archív adat).
A legtöbb formátum ma már alapból tömörített ha ezt egy kicsit is érdemes megtenni.
Szóval fileserver alá nem gondolnám, hogy jó.
DB fájlok. Na ez megint érdekes téma, de elég általános szokott lenni (főleg sok adatnál), hogy a DB a lassú, ha ezen még tömörítesz is csak rontasz a helyzeten.

FathoM

Fájl szerver alá szokás használni tömörítést, egyszerűen azért, mert random kontrollálatlan szemetet töltenek bele a júzerek, és nem takarítanak (a világ összes diszkje kevés fájl szerver alá), továbbá a tömöríthetetlen fájlok ellenére sem lesz annyira rossz a százalék en bloc, hogy értelmetlenné váljon, és mert az i/o performancia nem szokott gond lenni, hiszen a legtöbb fájlt nagyon ritkán matatják, csak elvan, mint a befőtt.

DB alatt szinte mindig kritikus az i/o performancia, továbbá jellemző az újraírás blokk szinten nem túl nagy blokkokkal, ergó itt amúgy sem lesz hatékony a tömörítés, ezért aztán nem is szokás használni.

A mail határeset: nagyobb forgalmú, szolgáltatói rendszernél az i/o performancia is kritikus, nem biztos, hogy belefér, ugyanakkor viszont nagyon hatékony tud lenni a tömörítés. Szóval esete válogatja.

Én egy tizenéve archivált céges backup szerver anyagán próbáltam ki tavasszal. Ott csináltam egy raid5-ös tömbből kialakított 12 TB-os btrfs partíciót.

Eredmény: 60..65 % közé nyomta össze az elmúlt évtizedben összegyűlt fájlokat, azaz 1/3-nyi helyet megtakarított.
Oka: nem is a tömörített szövegformátumok, hanem az évről évre egyre bőségesebb, további veszteségmentes tömörítésre alkalmatlan multimédia aránya sokat ront.
Emellett a full backupos szervereknél a Linux binárisokat és szöveges rendszerfájlokat, LOG fájlokat no meg a HTML fájlokat, sét a /var/lib/mysql könyvtárakról történt mentéseket jól nyomta. Annyira, mint a gzip (hiszen zlib-et használtam a btrfs tömörítésnél).

A sok bazinagy felbontással lefotózott villanyóra állás és hasonló értelmetlen méretű fotó mellett hiába az 50 MB-os doc fájl, ha abból is 49,5 MB a belefűzött ultranagy felbontású (minek) JPEG fotó.

Itt tartunk.

- filmek
- nagy felbontású jpeg-ek, ezekből álló doc-ok, ppt-k.
- mp3-ak, flac-ok

Ezek foglalják a háttértár túlnyomó részét és ezek nem nyomhatóak, csak veszteséges módszerrel (átkódolás értelmes felbontásra).

A deduplikáció segített volna még, azonban tavasszal az offline deduplikátor (bedup) ekkora partíción levő sok fájltól elhasalt. Így ezt nem tudtam kipróbálni.

A mysqlt is jól tömöríti, de a töredezéssel ott probléma lehet, bár a cow miatt egyébként is, úgyhogy én ezt replikált mysqlnél használom, időnként defragozom, vagy újramásolom az egészet. Így viszont van hgoy fele, harmada a tényleges helyfoglalás a file adatnál, ami winyónál pontosan ennyi io gyorsulást eredményez, ssdnél meg egyszerűen több fér.

( kleinie | 2014. 11. 01., szo – 09:35 )

Én elég régóta használok btrfs-t, soha nem foglalkoztam vele mennyire hatékonyan tömörít. Mivel az otthoni felhasználók zöme képet, videót, zenét tárol a gépén így nem sok értelme van. Ettől függetleneül be van kapcsolva és nem vettem észre teljesítménybeli különbséget hétköznapi használat során. Ami miatt jó lehet az a snapshot funkció. Pl.: rolling release esete (archlinux, mindenki azt hiszi, hogy a frissítéssel szétcseszi a rendszert), komolyabb rendszerfrissítés előtt csinálsz snapshot-ot, frissítesz, ha valami elszaródott, akkor visszaállítod (még soha nem volt rá szükség).

A tömörítés nem tömöríti a tömörítettet, intelligens. Amit nem említettél, az a blokkok checksumja, hiba esetén (szoftver vagy hw) a dmesgből kiderül pontosan melyik file tartalma (!) sérült, és azt backupból vissza lehet állítani, vagy legalábbis tudod a tényt. Pl. ext4nél vagy ntfsnél tudtommal ilyen nincsen, vagy legalábbis nem default, és ott ha nem csinálsz külön crc meg sfv fileokat, akkor nem tudod az integritást ellenőrizni. Ráadásul a metaadat duplikáció (default) miatt a kritikus metaadat sérülések önjavítók is, ami szintén jól jöhet bad sectornál...

( dblaci | 2014. 11. 01., szo – 10:09 )

A tömörítés nem tömörít mindent alapból, hanem egy autodetektálás után csak akkor, ha van értelme. Szóval a compress nem lassít semmit, viszont ha van mit tömöríteni, akkor pontosan annyit gyorsít, amennyi a lemez olvasási mennyiség csökkenésével megnyert idő minusz a tömörítés cpu igénye (ez gyakorlatilag elhanyagolható mai processzoroknál)

A torrentnél ha tele van a partíció durván töredezni fognak a fileok (alapból is), úgyhogy én azt javaslom, hogy ez a torrent partíció legyen külön a végső rendszerezett megtartott adattól, és a másolás ugye majd defragolja. Az online defragon nem tudom mire gondolsz, de ha a btrfs fi de /mnt/torrent -re gondolsz, akkor az csak a metaadatot defragolja, az is valami, de a fileokat nem.