Btrfs vs ext4 - adattárolásra

Linux-kezdő

Sziasztok!

Indítanék egy kis hitvitát fájlrendszer ügyben, mert kíváncsi vagyok mások véleményére.

Szóval adott a következő helyzet:
Van egy 200GB-os SATA HDD a SAMSUNG műhelyéből, amit adattárolásra használok: Zenék, videók, doksik, fotók, miegymás. Most épp NTFS, mert Windows alól is akartam használni, de hamar be kellett látnom, hogy a linux alatti teljesítménye szánalmasan lassú, így fogat szívva, de úgy döntöttem, hogy ismét linuxos fájlrendszerre formázom a diszket. Korábban már volt ext4 és nagyon meg voltam elégedve: gyors és még kettőspontot is lehet fájlnévbe tenni, stb.
VISZONT!
Sok helyen olvastam, hogy az ext4 egy zsákutca és a jövő zenéje a Btrfs lesz. Pont ezen felbuzdulva, mikor kukáztam az openSUSE 12.3-at az Ubuntu 13.10 javára, a rendszer fájlrendszere btrfs lett, ahogy a /home is. (a /boot ext2)
Bár még kísérleti FS, eddig semmi problémám nem volt vele.

És itt jön a kérdés maga:
Érdemes volna Btrfs-re formázni az adott diszket? Nyerek vele valamit? Másnak milyen tapasztalatai vannak? Vagy inkább maradjak az ext4-nél?
Várom a véleményeiteket!

  • 18967 megtekintés

( Zahy v | 2013. 10. 31., cs – 08:35 )

Flame on:

Ha ennyire bevallalos vagy, akkor akar UFS-t is hasznalhatnal. Fontosak az adatok? Hasznalj mar bizonyitott fajlrendszert: fenti UFS, vagy ext3! Nem annyira fontos? Akkor barmit ami experimental.

( GCS v | 2013. 10. 31., cs – 08:49 )

Anno XFS fan voltam, mégha sok kis állomány egy jegyzékben esetében lassú is volt. JFS általánosan megfelelt. Aztán jött az ext3 jobb elterjedése és végül az ext4. Manapság az utóbbira szavazok.
BTRFS még fejlesztés alatt van. Ami plusz feature (lesz) benne, az neked nem jelent túl sok előnyt. Annyira nem követem, de manapság a Grub valamilyen BTRFS ellenőrzéssel kezd. Lehet van már boot támogatás hozzá?

( uid_720 | 2013. 10. 31., cs – 11:59 )

Szerintem az EXT4-et még sokáig benne hagyják a kernelben, és ha ki is halasztják, nagyon hosszú időt hagynak az átállásra.
Habár a BTRFS-ről azt mondják, hogy ez a jövő útja, mégis elég kevés fejlesztő és tesztelő dolgozik rajta, és elég lassan halad az új feature-ök implementálása.

Én magam nagy híve vagyok a ZFS-nek, szeretem, mert mindenféle csodadolgot tud, különféle hibaellenőrzések, snapshot, ami hasznos, ha az ember pl. tranzakcionálisan akar rendet rakni a lemezen :-) A snapshot nem backup, de a semminél mindenesetre több, a véletlen törlés ellen jól véd. Per subvolume jól állíthatók a különböző lehetőségek, nagyon jól finomhangolható.

Fuszenecker_Róbert

( SzBlackY | 2013. 10. 31., cs – 17:39 )

Ha fontosak az adatok: egyelőre ext4, ha már tényleg stabil lesz (mondjuk a nagyobb disztrók fele be meri vállalni elsődleges fájlrendszernek), akkor in-place tudod updatelni.

Ha nem fontosak (pl. egy Letöltések mappát tartasz csak ott, amit legrosszabb esetben újra fel tudsz tölteni), akkor nyugodtan btrfs minden feature-el, jól jön a tesztelés neki :)

Szerk.: [disztro_troll]Amúgy meg nem elég, hogy átállsz openSUSE-ról ubira, még hirdeted is? :)[/disztro_troll]

BlackY

Süsü alatt egy csomó csomag hiányzott, külső tároló kellett, hegeszteni kellett, meg voltak idegesítő bugok.
Az Ubuntu sem hibátlan (néha csinál ezt-azt a Unity), de összességében tetszik. Nem is lassú és sokkal több csomag van hozzá. Fele annyit se kellett forrásból fordítanom. A SUSE-ban inkább csak a remek telepítője tetszett. Mellesleg miután kikapcsoltam az amazonos baromságot és Ambiance-ról Radiance-ra váltottam a Unity témát, igen kellemes rendszert kaptam.

Ubuntu 13.10 amd64

( locsemege v | 2013. 10. 31., cs – 18:32 )

Nagy tapasztalatom nincs ugyan a kérdésben, de picike van, s az pozitív. Ami előny lehet adattárolás esetén, hogy a btrfs tud tömörítést röptében, ami nem feltétlen hátrány, ha már épp archiválsz, de mégsem kell *.tar.xz-kkel megküzdeni, ha keresel egy kis file-t benne.

A gépemen ext4-et használok, mert úgy gondolom, manapság ez megbízható, s eléggé kiforrot. Csináltam live Linuxot, ott a /home-ot RAM disk-re tettem btrfs filerendszerbe. Ennek oka, hogy ha már RAM-ba dolgozom, legyen tömörítve, mert RAM-ból azért nincs sok, pláne egy bármilyen, akár idegen gépen, hiszen live disztribúcióról beszélünk.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Turion | 2013. 10. 31., cs – 20:38 )

Köszönöm a válaszokat!
Végül az ext4 mellett maradtam, mert a 90 gigás zenegyűjteményem és a fotóim fontosak.

Ubuntu 13.10 amd64

( dblaci | 2013. 11. 01., p – 13:17 )

Elég régóta használok btrfst (desktop root nak, homenak, szerveren is). De van ahol az ext4 esetleg jobb lehet.

A btrfs gyors, stabil, biztonságos, online defragolható, online méretezhető (shrink is). A snapshot nagyon hasznos tud lenni. A compress root meg home rendszernél durván sokat számít helyben és sebességben is (mivel a tömörítés kevesebb procit fogyaszt, mint amennyit a több adat olvasás/írás lassítana a winyó) kis winyónál, ssdnél meg pláne. Mivel online méretezhető, szét lehet bontani a rendszert sokfelé, és menet közben allokálni a helyet (lvmel), ha szükséges.

Amire eddig nem vált be, az virtuális gépek imagenek a tárolása, de nodatacow kapcsolóval az sem annyira vészes. A mysqlre sem ideális, ha sokat változik, mert töredezik a copy on write miatt. nodatacow ott is segít.

Ami lassú az az fsync, úgyhogy ami sok fsync et használ, pl. mysql innodb, ott a btrfs lassú lesz. Erre van egykét megoldás, amit nem írok le ide, mert új vitákat generálna, stb. :)

Ja ubuntun boot partíciónak sem ajánlom a btrfst, mert sparse file not found ra fog panaszkodni, ami kézi grub config átírással küszöbölhető csak ki. :)

Szóval btrfs rules :D

> stabil, biztonságos

Sajat tapasztalatbol mondom, h nem az. Hibas SSD firmware kinyirta az fs-t is (bar gyogyithato modon).

> mivel a tömörítés kevesebb procit fogyaszt, mint amennyit a több adat olvasás/írás lassítana a winyó) kis winyónál

Gondolom ezt ugy erted, hogy vannak bizonyos esetek, amikor igaz.

> nodatacow

Ezzel nem a lenyege veszik el, azaz fsck nelkul is konzisztens marad mindig az fs?

> Ami lassú az az fsync, úgyhogy ami sok fsync et használ, pl. mysql innodb, ott a btrfs lassú lesz. Erre van egykét megoldás, amit nem írok le ide, mert új vitákat generálna, stb. :)

Engem erdekelnek a tapasztalataid, plane ha egy kulon threadbe irnad.

> Ja ubuntun boot partíciónak sem ajánlom a btrfst, mert sparse file not found ra fog panaszkodni, ami kézi grub config átírással küszöbölhető csak ki. :)

A panaszkodason kivul nalam gondot nem okoz, a boot folyamat folytatodik rendben.

tompos

>stabil, biztonságos

Sajat tapasztalatbol mondom, h nem az. Hibas SSD firmware kinyirta az fs-t is (bar gyogyithato modon).

Egy fs-nek mennyiben dolga túlélni, ha az alatta lévő réteg hibás? Az a filerendszer engem érdekel, amelyik akkor is működik, ha az őt tároló eszköz tönkremegy. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Egy fs-nek mennyiben dolga túlélni, ha az alatta lévő réteg hibás? Az a filerendszer engem érdekel, amelyik akkor is működik, ha az őt tároló eszköz tönkremegy. :)

Valamekkora hibát tolerálnia kell(ene). Pl. a kritikus dolgokról illik tárolnia másolatot (mint btrfs-nél superblock), van, amelyik a checksumming miatt legalább felismeri, hogy hibás az alatta levő eszköz stb.

BlackY

Default duplán tárol minden metaadatot és system adatot (a kettő között nem tudom pnotosan mi a különbség) a file adat nincs csak duplikálva. Ez egyébként nagyon sok kis filenál + helyet és sebesség csökkenést okozhat, úgyhogy pl. gentoo portagenál ezt ki szoktam kapcsolni (mkfs.btrfs -m single ...)

Van továbbá checksum ellenőrzés file adatra és meta adatra is. :)

Köszi a pontosítást.

(közben utánanéztem, ZFS ismeri a copies opciót, így bad sectoros vinyó ellen is véd [https://blogs.oracle.com/relling/entry/zfs_copies_and_data_protection], valamiért úgy rémlett ezt a btrfs is tudja, csak nem voltam benne biztos; még nem ástam bele magam, csak 1-2 próba rendszer alatt használtam)

BlackY

Az elsőt nem kommentálom, mert nekem saját tapasztalatom elég sok van, és problémám csak kísérleti dolgoknál volt eddig, pl. a 3.11 ben frissen bevezetett skinny extent et régi filerendszerre utólag ráengedtem, és az online defrag meg balance tól segfaultolt a kernel. Adat nem veszett, nem is sérült, és kernel bugzillán küldtek patchet ami megoldotta.

Másik hiba xen virtuális gépet tároló filerendszer online defragolásánál volt, ez nem kizárt, hogy az O_DIRECT vagy egyszerűen egy régebbi kernel verziónak az együttállása miatt okzott hibát (de csak ritkán).

+ Egyszer volt olyan filerendszer sérülés, ami a memória random felülírása miatt következett be, azt nem írnám a btrfs rovására, ahogy te az ssd hibáját (???), és a recovery ott is nagyrészben segített (backup nem kellett visszaállítani).

>
> Gondolom ezt ugy erted, hogy vannak bizonyos esetek, amikor igaz.
>

Nyilván ott, ahol az adat jól tömöríthető, és a blokk eszköz sebessége a szűk keresztmetszet. Ez tipikus root filerendszernél (usr bin, lib, stb.) és home könyvtárnál (mindenféle sqlite, meg plain text dolgok). Egyébként a compresst a file tartalma alapján automatikusan kikapcsolja, ha nem jól tömöríthető, de ezt nem tudom pontosan megmondani mi a szabálya, de elvileg így van...
Egy példa: az usr/src ban két kernel forrás van most, 1.1gigabyte, a filerendszerben foglal 500 megát. Mivel file olvasásnál/írásnál a proci amit a kibe tömörítéshez használ elhanyagolható (pedig a zlib a lassabb van használva), gyakorlatilag 2x gyorsabb winyó írás/olvasás :) SSD nél ez nem számít, ott viszont a hely igen. Nekem egy 30 gigás ssdm van, nincs kedvem kiszámolni mennyi adat van rajta ebben a formában (usr és home) de nem 30 giga azt megmondom. :)

Nodatacow nál a meta adat még cow azért, csak az adat nem, tehát egy 100 gigás virtuális gép image file "sorban" van a winyón, akkor ha a virt gép a közepébe ír egy blokkot, akkor az a winyón fizikailag tök máshova kerül, nodatacownál meg oda, ahol eredetileg volt. Annyiban tényleg elveszti a btrfs az értelmét, hogy ilyenkor nincs checksum ellenőrzés, és a file tartalom sem garantált szabálytalan leállásnál. Viszont pl. snapshot, online méretezés, meg egyéb managelhető dolgok megmaradnak azért, ami nem rossz! Ja igen, compress sem lehet a nodatacow al együtt sajnos :)

>> Ami lassú az az fsync, úgyhogy ami sok fsync et használ, pl. mysql innodb, ott a btrfs lassú >> lesz. Erre van egykét megoldás, amit nem írok le ide, mert új vitákat generálna, stb. :)
> Engem erdekelnek a tapasztalataid, plane ha egy kulon threadbe irnad.

Jó, röviden: innodb insertnél fsync et meghívja, ami btrfsnél sokkal lassabb, mint mondjuk ext4nél. A valóságban ez azt jelenti, hogy nagyságrendileg, egy tömeges insert innodbbe tetszőleges finomhangolással (buffer méret stb.) mondjuk 15 perc btrfsnél. Kb. 5 perc ext4nél, ami még mindig sok szvsz, ezért én azt csináltam, hogy a mysql init scriptbe beraktam a libeatmydata libet, ami kihagyja az fsyncet, és így az idő lement 30 mp alá... Na és ez az amiért nem akartam ezt kiírni, ha nincs rá külön érdeklődés, mert itt mindenki lehülyéz, hogy ezzel oda az adatbiztonság, amire viszont leírom:
1.: nincs olyan adatbázis hosztolva nálam, ahol kritikus lenne egy tranzakció rögzítése. Attól, hogy minden fostos wordpress oldal innodbt meg tranzakciot, garantált lemezre írást használ, és ettől erőforrás igényes is, attól még nem lesz fontos, hogy a debug logjába bekerül e egy kínai login kísérlet vagy nem. :D
2.: replikálva van a mysql, és egy szabálytalan leállás után a korábbi slave lesz a master, és az első szabáyltalanul leállított mysql adatai mennek a kukába, ha az "új" slaveről sikerül visszaállítani a jó állapotot. Tehát nincs jelentősége, hogy egy elszállt szerveren konzisztens állapot marad-e (ami egyébként tapasztalat szerint így van), mert úgyis felül lesz írva az élő adattal.

> A panaszkodason kivul nalam gondot nem okoz, a boot folyamat folytatodik rendben.
Ez tény, és azt a rinyát is ki lehet kapcsolni, viszont két oka van, hogy nem szoktam mégse:
1.: 1 gigás boot partíció kb tökmind1 hogy milyen fs, nem oszt nem szoroz, se sebesség, se méret
2.: ez gentoon nem probléma, viszont ubuntunál igen, és mivel én ubuntut nem használok, csak másoknak telepítgetem, meg optimalizálom (pl. btrfs-re alakítással) ezért ott zavaró, ha egy frissítés után pl. újra jön a press any key rinya boot előbb. Ez nagyon kis probléma, de azért gondoltam megemlítem.

> ahogy te az ssd hibáját (???), és a recovery ott is nagyrészben segített (backup nem kellett visszaállítani).

Olvashatatlan lett az FS, csak mert azt hazudta, h kiirta az adatot, pedig nem. Ennyit tul kell elnie az en velemenyem szerint.
Egyebkent meg csak ez sem tuti, a btrfs levlistan kaptam a tippet.

> + Egyszer volt olyan filerendszer sérülés

Ha serult, azaz inkonzisztens lett, akkor az fs hiba.

> 2.: replikálva van a mysql, [...]

Szerintem amit leirtal, logkus.

> 1.: 1 gigás boot partíció kb tökmind1 hogy milyen fs, nem oszt nem szoroz, se sebesség, se méret

Viszont a "nem ajanlom" kitetel azt sugallja, h gondot okoz, jobb tisztazni.
Egyebkent nem mind1 szerintem, mert ha minden btrfs-en van, akkor pl. megoldhato konnyeden a 'time machine' szeru mukodes, pl. upgrade elott snapshotolva.
Okoz egyebkent gondot, nekem legalabbis nem mukodott a recovery mode btrfs root particioval, amikor legutobb probaltam (vmikor a Saucy felidejeben volt).

Kosz egyebkent, a libeatmydata trukkot nem ismertem.

tompos

>> + Egyszer volt olyan filerendszer sérülés
> Ha serult, azaz inkonzisztens lett, akkor az fs hiba.

Nem lett inkonzisztens, csak kernel panic ot okozott :D Adat nem veszett, egyáltalán.

> Okoz egyebkent gondot, nekem legalabbis nem mukodott a recovery mode btrfs root particioval,
> amikor legutobb probaltam (vmikor a Saucy felidejeben volt).

Passzolom, nem használok ubuntut, de ha mégis, és dist-upgradenél szétcsúszik, akkor gentoo sysresccd ről hozom rendbe. :D Láttam, hogy ha ubuntut alapból btrfs-re rakom, akkor nem is a fő subtreet mountolja, hanem eleve egy snapshotot ha úgy tetszik, ami nekem kicsit fura volt, viszont cserébe (és láttam, de nem próbáltam van erre valami apt kiegészítés is) van lehetőség arra, hogy upgrade előtt snapshottal gyakorlatilag egy tényleges "time machine" szerű recoveryt csináljon, ami nem rossz ötlet. Az még odébb van, hogy ez megbízhatóan, és átláthatóan működjön, de a lehetőség szerintem nagyon jó.

A libeatmydatat akkor próbáltam ki először, amikor a firefox 1 percre leakadt usb pendrive másolás közben. Ez ma már nem aktuális, mert:
az újabb kernelekben (nem tudom mióta, de nem olyan rég) ezeket az fsynceket külön választották blokk eszközönként, és nem globális (nem is értem miért nem így volt mindig)
+ a firefoxban is megszűnt asszem ez a szigorú fsync. :)

Szia,
számaim már nincsenek, viszonylag régen futottak bele a kollégák.
Emlékeimben kutatva a következőket találtam, azt hiszem anno ezen indultak el:
http://www.firebirdnews.org/?p=6421
http://www.firebirdnews.org/?p=7577
http://www.linux-magazine.com/w3/issue/78/Write_Barriers.pdf
Ennek lett a vége, hogy az adott ügyfélnél visszaálltak ext3-ra.
(Nála tényleg sok insert és update volt a többi ügyfélhez képest, ha jól emlékszem máshol nem volt ezzel gond (~2000 hasonló alkalmazás).)

Ugy adodott, hogy egy Debian alapu gepet SLES11-re kellett cserelni, ahol a korabban hasznalt ext4 nem tamogatott. A filerendszeren sok kicsi file van, minden percben frissul es keletkezik par szaz uj. Ext4-gyel gyari beallitsokkal is minimalis io wait-tel ment a rendszer, a btrfs minosithetetlenul lassu. Jelenleg rw, noatime, nodatasum, nodatacow, noacl, space_cache opciokkal megy a btrfs. Mi okozhatja a gondot, mit allitsak rajta?

Es ez? "If read-write access to an ext4 file system is still required, you may install the ext4-writeable KMP (kernel module package). This package is available in the online repository "SLES11-Extras" and contains a kernel module that provides read-write access to an ext4 file system. Be aware, that this kernel module is unsupported. "
Az alap ext4 modul ro, az ext4-writeable pedig nem supportalt.

( vol4 | 2013. 11. 01., p – 15:46 )

[troll on]
Mivel a "célszemély" mindössze 200 GB-os, valószínűleg nem mai csirke, így szerintem baromira mindegy, hogy "családi" használatra milyen fájlrendszer van rajta. Ha az adatok fontosak, legyen róla mentésed, ennyi...
[troll off]

Teljesen így igaz. 2008-as diszk. Jól megy, de néha NAGYRITKÁN előfordul (suse alatt többszor volt, itt csak 1x), hogy nem pörög fel elég gyorsan hideg bootnál és kézzel kell mountolni. Utána simán jó. Most a képekről 7z-vel szépen csinálok is backupot másik hdd-re, legalább a 10 gigás képarchívumról.

Ubuntu 13.10 amd64

( lajos22 | 2013. 11. 01., p – 19:41 )

Ha már hitvita kell, akkor mért Ubuntu SUSE helyett???...

Szóval. Ezzel a témával én is sokat töröm magam, de akárhány tesztet látok, az mind-mind az ext4 használatáról győz meg.
Legutóbb MySQL alá versenyeztettem ext4, xfs, és nilfs-t végül ext4 maradt. Mint ahogy rendszer alatt is ext4 van.

--
openSUSE 12.2 x86_64

Asszem' már leírtam.
Az OpenSUSE az elején sokkal szimpatikusabb volt... DE!
Néhány dologban szigorú. Alapból pl nem volt internet sem. Még a tűzfalon is portot kell forwardolni, nem elég nekem a router. Persze, vállalati OS-től ez várható ugye, de hát...
Aztán ezek végül is oké dolgok.
Amik idegesítettek:
Szinte MINDENHEZ külső tároló kellett, vagy build svc, vagy packman és sok mindent forrásból kellett fordítani. A csomagkezelőben gyakran volt ütközés, valami nem fért össze valamivel. Rengeteget kellett tehát hegeszteni rajta, mire jó lett.
Akkor ilyen hülye bugok vannak benne, hogy ha nem fordítok külön AMD-s kernelt, akkor a bootsplash 2x látszódik: egy 640x480-as és egy teljes képernyőre nyújtott.
Bootoláskor állandóan ata device not ready volt, még az üres meghajtók helyén is. Ez kernel bug mondjuk, Debian stable alatt is volt, 3.11-ben már nincs.
Tele van szegény süsü ilyen apróságokkal. Pedig alapból nagyon bejött a Yast, meg a jó KDE integráltság.

Akkor pedig miért ubuntu? Hát a 13.10 most épp frissebb csomagokkal jön, RENGETEG hozzá a netes segítség, a csomagok is többnyire ehhez készülnek és sokkal kevesebb külső tároló kell hozzá. A Unity, ha átállítom Ambiance-ról Radiance-ra, egész csinos. (noha néha bedoba 1-1 váratlan hibát szegény :S)

Összességében jól használható, ha az Amazonos gyogyiságot kiiktatja az ember.

Ubuntu 13.10 amd64

Igazából költői kérdésnek szántam, de ha már válaszoltál.
A tűzfalat telepítéskor nem kötelező bekapcsolni. Az alapból nem volt neted problémát én még sosem tapasztaltam.
A szinte mindenhez történet.. Lehet nekem vannak kis igényeim, de nekem csak a vlc, és valami kokek miatt van egy plusz tároló.
A többit sem tapasztaltam, bár nekem nincs semmi AMD-s cucc a gépben.

Ubuntut valamikor a 7-es környékén használtam. akkor elment, de nekem a suse vált be jobban, azóta sem volt túl sok gondom. Elvétve 1-2 dolog elhalálozik, amit a próbálgatással tönkrevágok. és hogy 10 perc körüli idő kell egy lekapcsoláshoz. (erre már fényt derítettünk máshol. valamit ACPI-ben kellene hegeszteni, de annyira nem zavar..)

No de amúgy, ahogy írtam fent is, fs-nél nekem mindig is ext3-4 vált be igazán. ahány teszt, annyi eredmény, de mindig az extX nyer. Ugyan néha sikerül tönkrevágni az fs-t, de melyiket nem lehet?.. :)

--
openSUSE 12.2 x86_64

( mhmxs v | 2013. 11. 01., p – 20:27 )

" az ext4 egy zsákutca és a jövő zenéje a Btrfs lesz." Az ext4 szerintem bőven ki fogja szolgálni az igényeidet, és azt a vinyót röhögve túl fogja élni.

( uzsolt v | 2013. 11. 02., szo – 17:06 )

Normál desktop használat esetén mennyire számottevő a fájlrendszerek közötti különbség?

( hory v | 2013. 11. 02., szo – 18:44 )

Sok helyen olvastam, hogy az ext4 egy zsákutca és a jövő zenéje a Btrfs lesz.

Ezen gondolkodj el. Hiszen koztudott, hogy a jovo zeneje a windows NT lesz.
(ironia, mielott komolyan veszed ezt is)

( bucko | 2013. 11. 05., k – 08:27 )

Olyan volt már, hogy jfs?
AIX alatt sokat tud. Linuxon van egy klónja, ami egyrészt gyengébb, másrészt volt egy időszak, amikor hanyagolták.
Sajnos disztrófüggő:
OpenSuse alatt 10+ éve használom, hibátlan még a legújabb kiadásban is.
Debian - a "biztonságosabb" verzió - alatt némi megterhelés után szétakasztotta a kernelt is néhányszor.

Előnye a sok apró file tárolásánál is kijön, akár 70% tároló is elég. Pl. mailszerver.

Egyszer használtam, amikor case insensitive filerendszer kellett, a jfs tud ilyet. Különösebb baj nem volt vele, de elég sok fícsör hiányzott, amit mondjuk a btrfs tud, úgyhogy amikor a case insensitive dolog végre megszüntetésre került, akkor a filerendszer is le lett váltva. Szerintem nem igazán fejlesztik, és eddig te vagy az első, akitől azt hallom, hogy versenyképes az eddig felsoroltakkal, és ez meglepő számomra, de nem zárom ki, hogy így van.

( sigellef | 2013. 11. 05., k – 13:13 )

ext3-mal vannak jó tapasztalataim, van olyan rendszerem, desktop is, server is, aminek a rendszere is ilyenen van. Van, amelyik már 2006 óta működik hibátlanul. Különösebb komplikáció áramszünetek miatt sem volt. Adatvesztéssel eddig csak szektorhibás merevlemez miatt találkoztam.
Próbaképpen használtam már ext4-et is, ext3-hoz képest különöseb változás nem érzékelhető, bár hosszabb távon még nem használtam.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( bucko | 2014. 01. 13., h – 16:39 )

Ha már hitvita.
Olyan már volt, hogy SAMSUNG -> azonnal kidobni?
Minél magasabbról, annál biztonságosabb lesz a hosszúidejű adattárolás!

Bár, ha még kettőspont is lehet a fájlnévbe, akkor______________

( salaud v | 2014. 01. 13., h – 19:02 )

Saját buta véleményem: Az a fájlrendszer, amin töredezettségmentesítőt kell használni, hibásan megtervezett, megírt fájlrendszer. Ilyenre adatot nem bízok, legyen bármilyen gyors, vagy röptében tömörítő.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.