[Megoldva] EXT3-4 / RaiserFS / XFS melyiket válasszam?

Linux-kezdő

Sziasztok!

Még a topic elején leszögezném: CSAK azokat kérdeznném, akiknek min. 2 FS-sel volt tapasztalata!

Jelenleg: EXT3 FS-t használok szerveren. (Gond nincs vele)
A szerver most egy új "tulajdonsággal" lesz bővítve: NAS (sw RAID1, 2 SATA3 HDD, otthoni felhasználásra) Ezért gondoltam, h az új HDD-knek (Vagy az egész rendszernek???) új FS kellene, h gyors legyen.
Változékony méretű adatok várhatóak: A HDD-k nyújtotta adatterület MAX 1/2-ét (de inkább kevesebb) torrent fogja teleszemetelni, másik felét peedig egyéb backup + FONTOS adatok.

Elvárás: Minél gyorsabb, és BIZTONSÁGOS FS-t szeretnék rá. (Az adatok duplikációját RAID biztosítja, a biztonságát pedig rendszeres backup)

Tehát, Ti mit ajánlanátok? Olvasgattam mind a 4 FS után, s a következőket tudtam meg -JAVÍTSATOK ha tévedek, ill hozzáfűzni valótok van-:

RaiserFS
-Naplózó FS
-GYORSABB mint más naplózó FS, DE a CPU-t jobban használja mint azok
-RENGETEG apró filee, és KEVÉS hatlmas file esetén gyorsabb mint az EXT
-LEGÚJABB verziója: RAISER4:
--Elődjénél 2x gyorsabb
--Megakadályozza az FS sérülését (DE HOGY? Hmm...)

EXT3
-Naplózó
-SOK alkönyvtárat jól kezel
-Hibatűrő???
-LEGÚJABB veziója: EXT4:
--Nagyobb méretű file-k tárolását teszi lehetőve
--Mélyebb könyvtárszerkezet
--Lessz hozzá (_elvileg_) defregmentáló
--Gyorsabb file törlés
--Más fontos nem jut eszembe

XFS

Előre is köszönöm szépen a segítségeteket!

UPDATE
Az FS-ekről több pontos infót szívesen fogadok bárkitől, amit be tudok írni a tulajdonságaikhoz, így könnyítve a választást.

Üdv.:
V007

  • 3195 megtekintés

( uid_194 | 2011. 07. 05., k – 13:36 )

Reiser4 nincs stock kernelben, nem is lesz. Reiser3 kb halott project, eleldegel meg egy darabig, de nem epitenek ra. reiserrel meg a kokorszakban jatszadoztam, sokat szivtam vele, azota nem neztem ra. Marad ext3/4.

Ext3-al ha nincs problemad, felesleges valtani masra, szerintem. (Nalam ext3 van fokent, kiveve par ujabb eszkozt, ahol ext4. Egyikkel sem volt meg semmi bajom.)

--
|8]

Akarsz kernelt patchelni? Es olyan FS-t hasznalni, ami a hivatalos kernelben nincs benne, es soha nem is lesz? Akarsz minden egyes kernel upgradenel azzal szivni, hogy feleroszakold az FS-t a kernelre, esetleg beleturj a kodba, mert conflictol?

Ha igen, akkor reiser4 kell neked. Ellenkezo esetben keruld el, messzire.

--
|8]

Rosszul latod. Reiser4 eleg szepen belenyul VFS layerbe is, ami DKMS-en at nem annyira tamogatott. 


$ zcat reiser4-for-2.6.38.patch.gz | diffstat | grep -v "^ fs/reiser4"
 Documentation/Changes                         |   12 
 Documentation/filesystems/reiser4.txt         |   75 
 fs/Kconfig                                    |    1 
 fs/Makefile                                   |    1 
 fs/fs-writeback.c                             |   50 
 fs/inode.c                                    |    1 
 fs/read_write.c                               |   13 
 include/linux/fs.h                            |   16 
 include/linux/mm.h                            |    1 
 include/linux/sched.h                         |    1 
 include/linux/writeback.h                     |    9 
 mm/backing-dev.c                              |    2 
 mm/filemap.c                                  |    2 
 mm/page-writeback.c                           |   26 
 mm/vmscan.c                                   |    5 
 176 files changed, 77774 insertions(+), 12 deletions(-)

De lehet probalkozni DKMS-iteni a legfrissebb patchet (lasd itt), ha szerinted lehetseges.

En nem mernek fogadni ra. Es amugy is erosen ketelkedem benne, hogy megerne-e a faradtsagot :P

--
|8]

Hat, ha van az embernek valami olyan drivere, ami kulonallo, es nem kell a kernel mar meglevo reszeibe belenyulnia, tehat kernel ujraforgatas nelkul, kulon modulkent forgatva is hasznalhato (reiser4 nem ilyen, csomo mas meg igen), arra kivalo a DKMS.

Egyebkent is az lenne a cel, hogy ilyesmi koddal alljon az ember a kernel fejlesztok el, mert nem szoktak tulzottan szeretni amikor random egyeb helyekre nyulkal bele egy-egy driver. Hacsak nincs arra jo indok, de azt meg akkor mar tegyuk kulon...

--
|8]

Nem hiszem hogy az interfészek absztrahálása jó pontnak számítana náluk, mert ha a komponensek közvetítővel kommunikálnak az akár meg 2x-3x-hatja a függvény hívások számát. De azt sem szabad elfelejteni hogy valami milyen gyakran kerül végrehajtásra. Nem tudom, nem hiszem hogy ez nekem jut eszembe először. Biztos meg van az oka hogy ilyen gány a kód.

nem valószínű, hogy a vanilla kernel részét képező filerendszer abandoned lenne, vagy kikerülne a linux kernelből. ahhoz ma már túlzottan elterjedt, és sokan szidnák érte okkal Linusékat. ez már nem a kezdeti időszak ext1el és Xiafsel, amiket csak úgy dobni lehetett. a Reiser4 hosszú távú sorsa viszont valóban kérdéses. akkor már inkább BrtFS, ha van legalább 1Gb memóriád. az ext4el egy éve még voltak problémák, de ma már az is megbízható. az ext3 természetesen konzervatív betonstabil megoldás.
jfs passz. xfs szintén jó választás lehet ha van hozzá szünetmentes táp, vagy notebookon megy normális aksival.

( dblaci | 2011. 07. 05., k – 14:10 )

"DE a CPU-t jobban használja mint azok" lehet, hogy ez elméletileg igaz, de szerintem már 600 mhzes prociknál sem volt jelentősége az összes többi szemponthoz képest... HA egyáltalán igaz. Csak a reiser3at próbáltam, a 4et nem, de az bevált minden környezetben. ext3nál sokkal gyorsabb.

( hnsz2002 v | 2011. 07. 05., k – 14:16 )

"A HDD-k nyújtotta adatterület MAX 1/2-ét (de inkább kevesebb) torrent fogja teleszemetelni, másik felét peedig egyéb backup + FONTOS adatok."
Hát akkor én rögtön legalább kettőbe venném a területet, egyik a torrentnek, másik az adatoknak.
--
Discover It - Have a lot of fun!

Márcsak azért is, mert más fájlrendszer kíván.
Torrent alá pl. XFS remek. Nagy fájlokat jól kezeli, gyors mert nincs nagy napló, cserébe nem gáz ha áramszünetkor egy-két chunk elvész, max letölti újra.
Fontos adatoknak, backupnak pedig mindenképpen valami bevált, kiforrott, garantáltan jól működő megoldást tegyél, pl. ext3.
--
Discover It - Have a lot of fun!

( uid_16313 | 2011. 07. 05., k – 14:38 )

Maradnék a jó, öreg, bevált EXT3-on.

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( fimikz | 2011. 07. 05., k – 15:00 )

kar, hogy linux speficikus a kornyezeted. hajszal pontosan azt irod le, amihez az ember egyszeruen ZFS-t hasznal, es megoldodott minden gondja-baja. hatha neked a btrfs lesz akkor a megoldas :)

( xclusiv v | 2011. 07. 05., k – 17:42 )

Reiser-t nem használnék, szóval marad az ext3/4. Jelenleg ext4-et használok notin, szerveren ext3-at. Ext3-al annyi a bajom, hogy baromi lassan töröl, ext4-ben ez meg van oldva.

( PTibi | 2011. 07. 05., k – 17:47 )

SW RAID? Biztos, hogy ez jó lesz neked?
+1 szavazat arra, hogy külön tömböt kreálnék backupra, és külön P2P-re. No meg a Raid tükör még nem lesz gyorsabb azért, mert raid, és csak tükör. + vinyóval már inkább lenne optimálisabb egy stripe tömb, 1 hdd backuppal.

Igen jó a SW RAID, azért mert:
-Otthoni felhasználás
-Kis költségvetés
-Nem olyan rossz az a SW RAID. CPU-t kicsit megfogja, de a szerver jelenlegi kihasználtsága is elég kevés.
-Persze tudom, h egy normális HW RAID jobb, de nem éri meg itthonra :(

1 szavazat arra, hogy külön tömböt kreálnék backupra, és külön P2P-re.

Ebben meggyőztetek, ezt így fogom csinálni. SŐT torrentre lehet, h RAID0 lesz

Szia.

Több, mint 10 éve használok Linux sw raidet nem kevés szerveren, eddig ha szétesett egy tömb, röviddel utána minden esetben kiderült, hogy diszk hiba okozta. Az eddigi tapasztalataim szerint stabil és jópofa dolgokra is képes.

A kérdezőnek: a tömb és a fájlrendszer közé javasolnék még egy lvm-et, egyszerűbb vele az élet.

Üdv: Zoli

( uid_2716 | 2011. 07. 05., k – 21:02 )

Ha a torrent nem csak seed-elni fog, hanem letölteni is, akkor a felsoroltak közül érdemes az ext4-et használni erre a célra, mert támogatja a fallocate() syscallt. Ha a torrent kliensedben is van támogatás (fallocate()-et vagy posix_fallocate()-et hív a file előzetes lefoglalásához), akkor nevezett helyfoglalás gyors lesz.

(Ha a torrent kliens nem foglalja le előre az igényelt területet (= sparse file-t készít, vagy még annyi sem), akkor amellett, hogy menet közben kifuthat a diszkből, még siker esetén is (a letöltés közbeni random seek-elt blokk-foglalás miatt) horror lesz szekvenciálisan végigolvasni a kész file-t. Ha a torrent kliens write()-tal "foglalja le" a helyet előre, akkor meg induláskor lassú.)

Nagy BTRFS fan vagyok, de csak annak ajánlom, aki mer veszélyesen élni :-)
A hétvégén jelent meg egy error a /-en, a btrfsck észrevette, de nem javította (na jó, végülis jogos, a btrfsck csekkeli a hibát, erre utal a neve is, javításról szó sem volt).

Viszont ha elkészül, és gyors is lesz, akkor nagyon fogom szeretni.

Fuszenecker_Róbert

P.S. Mivel csak a "/"-en van a hiba, elnézem neki. Továbbra is maradok a BTRFS-nél.

Szia, Szögi Kolléga!

Igazából nem mondta meg a btrfsck, hogy mi a problémája, csak annyit mondott, hogy error 2000 a 255-ös subvolume-on :-(
Annyi volt a hibajelenség (utólag visszagondolva), hogy megromlott az egyik git repo-m, amit nem bántam túlságosan, mert egy kísérleti projektemhez tartozott.

A 10+ éves adataim biztonságban voltak egy másik partíción, azon is BTRFS van, csak hibamentes :-) De biztos, ami biztos, archiváltam egyet (amit egyébként is 2-3 naponta szoktam).

Fuszenecker_Róbert

( veyron007 | 2011. 07. 29., p – 13:24 )

Megoldás:

Rendszernek: EXT4
Torrentnek: EXT4, DE csak azért mert nincs szünetmentesem :( XFS-t szerettem volna rá, esetleg Raiser4-et.
Backup: EXT4