Portál AbcLinuxu, 19. dubna 2024 18:58
16.10.2017 23:12
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
jak Milos Zeman.
17.10.2017 00:02
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
16.10.2017 23:39
vencour | skóre: 56
| blog: Tady je Vencourovo
| Praha+západní Čechy
sda1 -----------------------+
|
btrfs --- /boot
|
sdb1 -----------------------+
sda2 --- bcache --- LUKS ---+
| |
ssd btrfs --- /
| |
sdb2 --- bcache --- LUKS ---+
Disky jsou 2x 1TB + 32GB SSD cache, vše běžné lowend připojené do SATA (to ssd má dávat 400 read/150 write MB/sec, takže na dnešní poměry nic moc), bcache jede v módu writethrough. Pocitově a podle sluchu disky méně seekují a nabíhání aplikací je svižnější. Ale není to jako mít vše rovnou na ssd, to je jiná liga. Moje idea byla, že v cache budou hlavně často používané inody, tj. často spouštěné aplikace nebo milión ini souborů KDE - to to zhruba splňuje. Při pokusu s writeback disky méně chroupaly i při zápisech, ale jak jsem psal, raději bezpečnější mód. Teď mám taky volné M.2, tak by bylo zajímavé vyzkoušet. Cache device jde odebrat a zase přidat jiné, tak až se mi dostane do ruky nějaký M.2 SSD, budu zvědavý, jaký bude rozdíl.
19.10.2017 23:56
vandrovnik | skóre: 21
20.10.2017 08:11
Max | skóre: 72
| blog: Max_Devaine
Já jsem kdysi používal zásadně reiser4, protože reiser4 natrhl prdel nejen všem ostatním filesystémům, ale i reiseru 3.6 (nebo jak se ta začleněná verze tenkrát jmenovala). Ale pak jsem toho nechal, protože
Zkrátka a dobře, začátkem roku 2010 už byla údržba reiser4 neudržitelná a navzdory jeho rekordnímu výkonu jsem se na něj vybodnul a začal jsem místo něj používat Btrfs, který je prostě v kernelu.
Co koukam na diskuse kolem btrfs tak se skoro cítim vysmátej, že se mi to vyhlo ...
No jasně, takhle vysmátá si připadá spousta lidí, kterým cosi zásadního nedocvaklo — a sice jak obrovský je rozdíl mezi zastaralým filesystémem typu Ext4 a filesystémem s odolností proti poškození dat, s CoW a s opravdovým RAIDem (který strčí do kapsy všechny historické pseudo-RAIDy, které po poškození dat na jediném disku začnou náhodně vracet náhodné smetí).
Zatímco ti, kterým zásadní převrat v oblasti filesystémů (zahájený ZFS) unikl, dál v poklidu ztrácejí svá data, ať už potichu nebo hlučně, jejich konkurence s Btrfs se tomu směje od ucha k uchu a dělá si jen tak pro legraci atomické snapshoty. Takže asi tak.
Pro osobní použití mám na všech svých strojích Btrfs cca od roku 2010.
No jasně, takhle vysmátá si připadá spousta lidí, kterým cosi zásadního nedocvaklo — a sice jak obrovský je rozdíl mezi zastaralým filesystémem typu Ext4 a filesystémem s odolností proti poškození dat, s CoW a s opravdovým RAIDem (který strčí do kapsy všechny historické pseudo-RAIDy, které po poškození dat na jediném disku začnou náhodně vracet náhodné smetí).
Není náhodou nutné CoW u databází vypnout?
A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?
19.10.2017 18:29
Jendа | skóre: 78
| blog: Jenda
| JO70FB
A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?Je horší v tom, že nechecksumuje data. A lepší v tom, že na rozdíl od btrfs „RAIDu“ funguje i v degradovaném režimu a neobsahuje podivné bugy.
Horší je hlavně v tom, že při poškození dat na kterémkoliv (jednom!) disku zničí data na všech discích.
Ještě jednou: Zničí všechna data kvůli poškození dat na jednom disku.
A: A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?
B: Je horší v tom, že nechecksumuje data.…
C: …Horší je hlavně v tom, že při poškození dat na kterémkoliv (jednom!) disku zničí data na všech discích.Řeč byla stále o tom, v čem je lepší či horší RAID v LVM.
Není náhodou nutné CoW u databází vypnout?Doporučené to je, například dokud PostgreSQL nebude umět vhodně používat API, které se skrývá za
cp --reflink a podobnou funkcionalitou. Nutné to samozřejmě není, ale může to mít negativní vliv na výkon (v případě rotujících disků; v případě SSD to není až tolik podstatné).
A co RAID v LVM? Je lepší nebo horší ve srovnání s RAID v BtrFS?
Pozor na věc, v LVM žádný použitelný RAID není. Technologie typu dmraid i (starší) mdraid vytvářejí pseudo-RAID, který (stejně jako hardwarový pseudo-RAID) nechrání proti chybám dat na jednotlivých discích. Chyby můžou vzniknout nechtěným přepsáním části disku při údržbě systému, případně jako důsledek řady různých hardwarových a softwarových chyb.
Pokud je poškozená RAID1 replika u Btrfs, filesystém to zjistí, opraví to podle funkční repliky a nikdy nevrátí špatná data. U pseudo-RAIDu dojde k tomu, že se budou náhodně vracet nesmysly, jak se z toho RAID1 pole prokládaně čtou bloky. Jednou z jedné repliky, pak zase z jiné. Takže jakmile dojde k poškození dat, dokonce ani není zaručeno, že dvě čtení téhož souboru vrátí totéž.
RAID5 v LVM (nebo ve starém mdraidu nebo i hardwarový) je ještě horším rizikem. Dokáže se prý vyrovnat s úplným selháním jednoho disku. Ano, ale jedině za předpokladu, že ten disk přestane fungovat zcela náhle a nevrací už pak žádná data, natož neplatná. Jenže co když se na jednom disku poškodí data? Znám případ, kdy došlo k přepsání části jednoho disku nulami. Části, která neobsahovala RAID5 metadata, takže metadata tam zůstala a disk se dál tvářil jako součást RAID5 pole. A pak (bohužel) nastal resilvering, který kvůli poškození jednoho disku zničil všechna (všechna!!!) data na celém poli. Tohle by se s Btrfs nikdy nestalo, protože Btrfs má checksumy. Pozná, který blok vrací nesmysly, a ať už je ten blok pro daný stripe paritní nebo datový, problém dokáže opravit (nebo prohlásit za neopravitelný, je-li to jeden disk, RAID 0 a podobně). Nebude ale vracet náhodné smetí.
Samozřejmě to není dokonalé — jistě bude v Btrfs checksumech hashovací kolize, že ano. Ale Btrfs prostě pomáhá tím, že snižuje pravděpodobnost vrácení poškozených dat filesystémem o nějakých deset desítkových řádů nebo víc. Takže z jevu, který by se ve větším (PB až EB) datovém centru stával často (kdyby tam byl klasický FS), se najednou stane cosi prakticky nemožného (při dnešních technologiích a kapacitách disků).
(Ještě je pro zajímavost dobré dodat, že i na jednom rotujícím disku je Btrfs bezpečnější než jiné filesystémy, protože může mít (atomicky udržované) repliky metadat. Poškozená data jsou sice neopravitelná, ale poškozená metadata se (automaticky) obnovit dají, pokud je druhá replika v pořádku. Pokud jde o SSD, tam se v Btrfs repliky metadat nedoporučují a implicitně jsou vypnuté, protože SSD má zpravidla ve svém řadiči deduplikační algoritmus, takže replikované bloky metadat by beztak nikdy nesplnily svůj účel (redundance) a řadič SSD by musel dělat copy-on-write ošklivosti při pozdější změně těch metadat.)
19.10.2017 18:31
Jendа | skóre: 78
| blog: Jenda
| JO70FB
a s opravdovým RAIDemOpravdový RAID se pozná podle toho, že když vypadne disk, tak nejde přimountovat read-write? Nebo podle toho, že má ve status page napsáno write hole still exists, parity not checksummed?
Ale no tak. Že by krátká paměť? Tohle jsme řešili asi pětkrát, co má splňovat opravdový RAID (a proč to, čemu se dosud říkalo RAID, ve skutečnosti nikdy nesplnilo své sliby kolem redundance). Vše jsem už pod některými tvými výkřiky vysvětloval možná i víckrát než pětkrát. Co takhle si to zkrátka dohledat a nepapouškovat pořád dokola zavádějící otázky a jiný FUD?
Pokud je o status page: Všiml sis doufám, (1) že varování se netýká RAIDu 1, 0 a jejich kombinací a (2) že status page nemusí být aktuální? Některé z oprav, o kterých ses (na status page i jinde) jistě také dočetl — jen jsi je nějak zapomněl zmínit —, už jsou nějakou dobu v kernelu.
Myslíš si opravdu, že RAID má být je něco, co se rozsype a začne vracet náhodný čaj, kdykoliv jeden jediný disk začne vracet náhodný čaj? Ne, to opravdu není RAID — to je AID be R. Btrfs přesně proti tomuhle chrání, zatímco zastaralý pseudo-RAID nikoliv (a resilveringem následně zničí všechna data — i to jsem vysvětloval několikrát).
Fakt je mi záhadou, proč se snažíš všude vtěsnat kousek FUDu proti Btrfs. Takhle v debatách fungují nejrůznější popírači IPv6, popírači systemd, popírači Btrfs, příznivci parních strojů nebo koňských povozů… Asi takhle: Pokrok v oblasti filesystémů tady bude, ať se ti to líbí nebo ne.
Ale no tak. Ty jsi někdy neuvěřitelně zaťatý. To, že checksumy jsou skvělá záležitost, nikdo nezpochybňuje. A to, že btrfs je schopno identifikovat porušené disky na základě chybné sumy před tím, než se disky jako celek tváří jako nefunkční, je také vynikající. Problém je v té následné funkcionalitě. Já jsem si RAIDem na btrfs zatím nehrál i když mám btrfs na mnoha discích. Nicméně, pokud btrfs se přepne do RO režimu a neumím ho přesvědčit, aby dále fungovalo normálně, je v tom něco špatně. Je to pro mne arogance vývojářů, kteří uživatele nutí do režimu, který nechtějí.
Je to trochu podobné, jako když jsme před pár lety vedli vážnivé debaty, že df pro určování volného místa na btrfs volumu nemá smysl. Tehdy jsem argumentoval, že kapacita toho disku je něco jako měřitelný prostor v matematice. Měřitelné množiny jsou mnohdy velmi divoké, v mnohadimenzinálních prostorech (i nekonečně dimenzionálních) a jde na nich zadefinovat míra. BTRFS volume je prostor o konečném množství prvků a zadefinovat smyslupnou míru by problém být neměl. Naštěstí se hodně zlepšili a v současnosti df dostačuje pro základní představu o volném místě. A pokud někdo chce a potřebuje detail tak btrfs filesystem detail odpoví. Tady už se arogance zbavili.
Druhý případ je arogance výrobců aut, kdy auto zastaví a nejede dál, protože mu někdo nevyměnil olej nebo podobnou blbost. Tady je to obdobné. Ano standardní funkcionalita na RAIDu s vypadlým diskem je extrémně riziková, na druhou stranu pokud uživatel potřebuje dočaasný čas přežít s tímto rizikem tak systém by mu to měl umožnit. Podobně jako to, když potřebuji s autem dojet, tak mi sice může nadávat a upozorňovat mne, ale musí jet. V extrémním případě může jít o život.
20.10.2017 12:35
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Dejme tomu, že mně ta funkcionalita chybí, ale v PHP ji určitě dopisovat nebudu a raději zvolím jiný filesystem.Tvoje volba.
20.10.2017 10:28
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Tohle jsme řešili asi pětkrát, co má splňovat opravdový RAIDAno, například by se tam nemělo stávat, že v nejběžnější konfiguraci po výpadku jednoho disku přestane jít používat. Pak to totiž není Redundant a Independent, ale jenom AD. To není FUD, to je prostě fakt a každý si to může zkusit.
Myslíš si opravdu, že RAID má být je něco, co se rozsype a začne vracet náhodný čaj, kdykoliv jeden jediný disk začne vracet náhodný čaj?Vzhledem k tomu, že se mi na asi 80 TB*let tohle zatím ani jednou nestalo, zatímco btrfs se mi rozsypalo několikrát, považuji za lepší používat ten „nebezpečný“ RAID. Já výhody checksumování nerozporuji, ale prostě v současném stavu není btrfs vhodný na produkci. Doporučil bych ZFS, ale tam je zase problém že zpool nejde zmenšovat a vyhazovat z něj disky.
31.10.2017 16:02
Max | skóre: 72
| blog: Max_Devaine
.. treba Oracle ( puvodni autori ) , Facebook, Google , SUSE .. same malicke firmicky co nemaji dostatek lidi
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.