Vlákno názorů k článku
Red Hat končí s Btrfs, zřejmě nadobro
od Martini - A zase tie flame wars na ZFS, btrfs,...
-
Martini (neregistrovaný)
A zase tie flame wars na ZFS, btrfs, dokonca WAFL od NetAppu, ktorý stojí raketu a je ešte viac proprietary ako bývalo ZFS alebo je v podaní Oracle. Ale o to nejde.
Určite nikomu nemohlo uniknúť, že RH prešiel u RHEL7 z ext4 na XFS. Možno blbé rozhodnutie, možno nie. Ale XFS je veterán z roku 1994, a kto sleduje aspoň phoronix.com alebo nebodaj kernel patche, tak si určite všimol, že XFS pomaly naberá kód, ktorý zabezpečí COW, snapshoty, post-write deduplikáciu, checksumy (metadata už checksummed sú), atd. Vôbec by som sa nečudoval, ak RH spolupracuje s SGI na vývoji a obohatení XFS do formy, ktorá bude konkurovať ZFS či Btrfs. A áno, XFS nie je a asi nebude mať volume management ako btrfs alebo ZFS, ale načo znova vymýšľať koleso, keď tu máme LVM2? Integrovaný RAID má už dávno, a XFS dokonca detekuje parametre LVM2 RAID a nastaví sa podľa neho pre lepší beh, a to už dávno. Držme si palce, pomaly ale rock-solid. -
Filip JirsákStříbrný podporovatelJak LVM2 RAID zajistí přečtení správných dat v případě,kdy každý disk vrací něco jiného? Jak zajistí kopírování pouze užitečného obsahu (nekopírování nepoužívaného místa) při rebalancování pole (třeba po náhradě disku)?
-
Kde jsou ty doby, kdy na SCSI discich bych sektor o neco vetsi nez 512 byte, aby tam slo ulozit aplikacni checksum.
Kolikrat delate rebalancovani pole a pridavani disku do raidu? Z poslednich zkusenosti kdyz jsem prechazel pres 16TB hranici tak to vyzadovalo dokonce prechod z 32b na 64b OS. Pokud chcete/musite casto pridavat disky, tak je lepsi mit mensi MD pole z nekolika disku (4,6,8) a pak pridat dalsi sadu a spojovat to az na urovni LVM pres linear append. Ale s touto organizaci musite planovat od pocatku.
Duvod proc upoustim od pridavani dalsich disku do MD je, ze je to takova krizovka jenom.. vykon FS jde do kytek kvuli tomu ze byl naformatovan s puvodni organizaci poctu stripes. Nekdy se tomu lze vyhnout, kdyz vim ze tam bude nakonec jiny pocet disku (doplnenych v ramci kratke doby na finalni stav), a v tom pripade formatuji uz s finalnim poctem stripes (a suboptimalni vykon to ma tedy do doby nez se to pole rebalancuje).
-
"...je lepsi mit mensi MD pole z nekolika disku (4,6,8)..."
Tyhle pocty se doporucujou i u ZFS poolu= vetsi pocet VDEVu s mensim poctem disku max 10 optimalne tak 6-8ks. Pokud mas 36TB pool alias 6vdev x 6disku po 1TB a chces zvetsit pool upgradujes 1 vdev.
Je to sice nevyhoda ZFS ze musis upgadovat "po skupinach" ale to je zas vyvazeny jinyma vlastnostma.Dat do 1 VDEVu mraky disku je magorina protoze kdyz odejde 1 je sance ze odejde vzapeti i druhej (obzvlast kdyz jsou ze stejny sarze) a ZFS umi max RaidZ3 alias max ztrata 3disku v 1 VDEV.
Kdyz se pak provadi resilvering za "padle kamarady" je tu znova realna sance ze zacnou chcipat dalsi disky...Meli sme tu sveho casu o tom pomerne rozsahlou debatu:
https://forum.root.cz/index.php?topic=12850.60 -
