TeraByte-os filerendszer

[quote:662b0fe9f7="STP"]
Nem 'production' szerver.
Nincs Samba, NFS, adatbázis, mail... Semmi
Csak FS. Ide szinkronizálunjuk le a production szervereket.

Akkor meg egyértelműen plain old ext3 :)

Csak megjegyezném, hogy a 'tera' SI-előtag egy db 'r' betűvel írandó.

..és a egyenlőre is gondolom egyelőre akart lenni. :) ..bocsi

Szóval nekem az XFS nagyon bejött! +1p XFS

Üdv: M.

nekem az ext3-al sincsen gond 1.2 Tbajtnal.

Én láttam már szívást XFS-sel. Sőt láttam már magától meghalt ext3-at is. Sok ember tapasztalatából rengeteg utánaolvasással azt a konzekvenciát vontam le, hogy az XFS elég stabil, ha nem teszed ki extrém körülményeknek. Főleg kényes valamiért, mint NFS alatti fájlrendszer (Ilyenkor ext3-at javasolok, minden esetben). Szóval ha csak fájlrendszerként akarod használni, monnyuk egy adatbázis alá, akkor tökéletesen megállja a helyét tapasztalataim szerint. Másrészt meg olyan előnyökkel rendelkezik, amivel ext3 nem. xfs_freeze és xfs_snapshot nagyon hasznos archiváláskor és esetleges merészebb húzások alkalmával, ha az éles rendszeren bütykölsz vmit és évekig tartana mentésből visszaállítani. Másrészt gyorsabb is szinte minden esetben, mint az ext3. Hátránya lehet a te esetedben, hogy CentOS (és RHEL) NEM tamogatja az XFS-t kerneleiben AFAIK. Sőt, semmit nem támogat ext2/3-on kívül. De ez áthidalható ;)
Mindeközben nem lehet elégszer hangsúlyozni, hogy MENTENI, MENTENI, MENTENI :twisted:

Ja és még válaszok ;)
[quote:abb075a1cc="STP"]
Linux (3Ware, CentOS, LVM) alatt, ki milyen módon próbálná elkerülni az esetleges FS 'korrupciót'?

Ezért igazán sokat nem tehetsz. A konzisztens fájlrendszer-állapot biztosítása az FS kódjának feladata. A te feladatod az, hogy ha mégis összeratyizza magát, gyorsan helyre tudd hozni. Mentés itt sztem az egyetlen megoldás. Esetleg csinálhatsz olyan XFS-sel, hogy cronból csinálsz snapshotot a filerendszerről mondjuk minden órában és törlöd a 3 órával ezelőttit. Így ha van is korrupció, elméletileg a snapshot ép maradhat attól még hogy valahol tranzakciós hiba volt a filerendszerben. Ekkor fs-check és a snapshotot visszaállítod. De ha tud vki többet-jobbat, ne fogja magát vissza! ;)

[quote:abb075a1cc="STP"]
Particionálás?
LVM 'darabolás'? (mivel jól meghatározható 20-100GB-os részekre vágható az adathalmaz)

Tulajdonképpen a partícionálás ideális esetben csak magas szintű logikai felosztást kellene hogy reprezentáljon. De nyilván van technikai érdek is mögötte. Előny lehet, ha minél több kis partíciód van és összeomlik az egyik. Így a többi sértetlen marad. Ellenben ha sok kis partíciód van, az sok nyilvántartáskezelést is jelent, hiszen minden egyes partíció fájladminisztrációját kezelni kell és struktúráit nyilván kell tartani, ami ugye eléggé hazavághatja a rendszer teljesítményét. E két oldal között kell megtalálnod az egyensúlyt. Én konkrétan a te esetedben olyan 300-400 Gb-os partíciókat hoznék létre, ha feltételezem, hogy 2 Tbyte-os lesz a teljes tárolókapacitás és tudom, hogy az adatok kb 200 Gbyte-nyiak kezdetben, így 50%-ot ráhagytam minden partícióra, az esetleges bővítést feltételezve, plusz a snapshotoknak is kell hely a partíción.
[quote:abb075a1cc="STP"]Egyéb 5let? (Szalag, másik szerver nem játszik, egyenlőre)

Szalag egyértelműen. Ezt másik szerver sem pótolhatja. Másik szerver max a magas rendelkezésreállás esetén jöhet jól, már ha ez igény a te esetedben.

[quote:10c9f397e9="STP"]üdv!

Linux (3Ware, CentOS, LVM) alatt, ki milyen módon próbálná elkerülni az esetleges FS 'korrupciót'?

Kérdések (flame mentesen):
FS? (ext3, XFS, JFS, Reiser3)
Particionálás?
LVM 'darabolás'? (mivel jól meghatározható 20-100GB-os részekre vágható az adathalmaz)
Egyéb 5let? (Szalag, másik szerver nem játszik, egyenlőre)

Mentessel pl. :DDD Egyetlen fajlrendszer sem ved meg a hulyesegtol, vegtelen torlesektol...