Lesk a bída Btrfs aneb nevěřte diskům a paranoidně zálohujte (diskuse)

[saly]

Ajaj, to není moc pozitivní příspěvek. Na btrfs jedu na laptopu už dýl (SSD, aktuální jádra pod Arch Linuxem) a pohoda. Chce to ale jednou za čas pustit balance i na tom single disku, protože sice volné místo na disku je, ale nejde jinak využít. Teď jsem na btrfs přešel na Cubieboardu (SATA Seagate) a odvážil jsem se ho teď nasadit na nový disk (WD RED 3TB), který je v testování a nahradí mi stávající v NASu (2x disk Seagate Barracuda na ext4). Dám ho tam ovšem až vyjde nová verze Turris OS, kde bude novější jádro než 3.10, protože zas tak odvážný nejsem, vzhledem k tomu, že tam mám i zálohy.

[pavlix]

Tak o laptop můžeš celkem lehce přijít o celý, takže se potřebě zálohování nevyhneš.

[saly]

Jo jo, to dělám ... na již zmíněný NAS s btrfs

[pavele]

Díval jsi se na smart toho WD RED 3TB? Hlavně na údaj o parkování hlaviček.

[kapo]

Tak moje 2 Redy 3TB maji po snad 2 letech cca 50. Zato Seagate ST3000DM001 ma 20500 :).

[Aleš Kapica]

SSD? A Btrfs jen v single modu? Pravděpodobnost že přijdeš o data je zhruba stejná jako že se aktivní motocyklista dozije ve zdraví a bez nehody padesátky.

[Jendа]

Mám 1.7 TB dat na ADATA SSDčkách, která jsem zapsal v létě 2012. Naprasil jsem na to teď check (není to FS, je to přímo na těch devicech) a pustil jsem to, počkej si tak den, než to doběhne.

[Aleš Kapica]

Pokud jsi to tam nalil r.2012 a teď se to chystáš přečíst, tak v tom problém není. Taky máme doma starší Asus eee 901 s SSD diskem, který furt žije. Problém SSD disků je v tom, že většinou umírají smrtí náhlou a bez varování. Proto mám nad nimi Btrfs v raid1. Chcípne-li jeden, tak předpokládám že na druhém ta data zůstanou, přinejmenším do doby, než je zreplikuji na SSD které ten mrtvý nahradí.

[Jendа]

Jinak dlužím vysvětlení, proč to nedopadlo: tomu stroji zrovna odešla paměť (memtest hlásí červené řádky), musím se tam někdy vypravit a najít a vyndat vadný modul.

[saly]

Mám Samsung SSD PRO, takže doufám, že když na něj dávají záruku 10 let, že si za ním stojí.

[Jardík]

Záruku ... na výrobní vady. Řeknou ti, že je to opotřebení a máš smůlu.

[mimi.vx]

tak to je celkem vysoka, vzhledem k tomu ze vetsina motorkaru ma 45+

[Odin1918]

+1

[Odin1918]

Znate vubec nejake motorkare pane Kapica? Ja jich znam spousty a hodne jich ma jiz padesatku na krku.

SSD? A Btrfs jen v single modu? Pravděpodobnost že přijdeš o data

Co je na kombinaci btrfs + ssd spatneho? Mate nejake konkretni poznatky?

[Aleš Kapica]

Znám jich docela dost. Naštěstí ale ty šťastnější, co své nehody víceméně ve zdraví přežili. Kolega, který je o patnáct let mladší má ale statistiku horší.

Pokud jde o kombinaci, blbě jste to pochopil. SSD je samo o sobě riskantní médium. Což Btrfs je schopno ošetřit, je-li v módu raid1 tedy nad dvěma SSD disky. Je-li v single módu, je to stejný risk, jako u kteréhokoliv jiného FS. Takhle ho používám pouze tam, kde se ukládají pouze zbytna data - zurnalovaci soubory sheepdogu, která se průběžně prepisuji na sice pomalejší, ale trvalejší média.

[Heron]

Díky BTRFS csum chybám jsem takhle přišel na vadnou paměť (non ECC).

[Aleš Kapica]

Podle mě je v jaderném modulu Btrfs buga. Dokonce se mi ji jednou podařilo odchytit, jenže jsem jí nepřikládal větší význam a nikam neuložil. Bohužel později už jsem to "štěstí" neměl. Stroj při ní totiž vytuhne tak, že ji nelze vydolovat. Do logu se neuloží a na monitor se vypíší už jen hlášky které jsou jejím důsledkem.

Dochází k ní pokud se přesouvají extenty se kterými se zrovna pracuje, z nebo na fyzické zařízení, a Btrfs je v single modu.

Když byly extenty Btrfs v raid1, nebo zařízení bylo typu sw raid1 nebo raid6, problém nenastal.

Stejně tak nenastal pokud systém extenty nepoužíval.

[Aleš Kapica]

Ještě k tomu jak se mi ji podařilo odchytit. Byl jsem na tom stroji přihlášen přes ssh a sledoval přes dmesg s parametrem -w jak se přesouvají Btrfs extenty. Pak to najednou vyzvracelo tu chybu a stroj byl ve stavu zombie - tj. žil a nežil. Přestal komunikovat, jen pingal.

[Jendа]

Vypadá to tedy, že mi Btrfs právě zachránil zadek, protože mne upozornil na poškozená data, která by běžný filesystém přešel bez jakéhokoliv varování!

Není nad tím v dmesg taky hláška, že disk vrátil vadný blok, tedy by se to odchytlo i bez btrfs?

Já mám mismatche na serveru s ECC, asi tak jeden za 100 TB a půl roku, a vůbec nechápu, jak se to může stát. Disky přece používají samoopravné kódy a SATA komunikace po kabelu je taky chráněna CRC. Škoda, že btrfs ani MD nepíšou třeba obsah toho bloku nebo nějak víc informací (byl to bitflip? je celý blok nulový?) a protože je to RAID, tak ho to hned opraví z druhé kopie a nejde to diagnostikovat.

[Cohen]

Vypadá to tedy, že mi Btrfs právě zachránil zadek, protože mne upozornil na poškozená data, která by běžný filesystém přešel bez jakéhokoliv varování!

Není nad tím v dmesg taky hláška, že disk vrátil vadný blok, tedy by se to odchytlo i bez btrfs?

Právě že není, ve výpisu dmesg není nic, co by naznačovalo, že by se čtením z toho disku bylo cokoliv v nepořádku. (Minimálně tedy nyní, co tam případně bylo při tom prvotním zápisu dat už teď bohužel nezjistím.) Chytá to až Btrfs na úrovni kontroly kontrolního součtu dat.

Možná ale nebude od věci nechat na tom stroji řádně proběhnout memtest.

[Jendа]

Možná příčina těchto mismatchů byla vysvětlena v diskuzi. Ano, mám na RAIDu swap.

[elenril]

Nemůžu si pomoct, ale to btrfs mi pořád přijde docela podezřelé. Hlavně tím, jak do sebe cpe hromadu věcí, co IMO mají být v LVM/DM. To je takový problém dodělat ty checksumy do ext4? Gůglení naznačuje, že na něčem takovém se dělá/dělalo, ale moc konkrétních informací jsem nenašel.

Jinak samozřejmě zálohuju, bup mi poskytuje každodenní zálohy s deduplikací. Za skoro dva roky a zhruba 15 systémů je to na ~150GB (checkout latest verze každého mají dohromady asi polovinu). Jen bych asi měl mít víc fyzicky vzdálených kopií.

[Heron]

Hlavně tím, jak do sebe cpe hromadu věcí, co IMO mají být v LVM/DM.

Některé vlastnosti by při rozdělení na jednotlivé vrstvy nešly dosáhnout (nebo ne tak elegantně). On totiž btrfs není "mechanické" sloučení raid, partition managera, jak se to často chybně vykládá, btrfs na vrstvy nelze rozdělit. Vše vychází z jednoduchého konceptu cow, nad kterým lze poměrně elegantně kouzlit.

Samozřejmě, projekty LVM / MD tady budou stále dál, nezmizí (už jen proto, že exportují blokové zařízení).

To je takový problém dodělat ty checksumy do ext4?

Je. ext4 i xfs mají checksumy metadat.

[trekker.dk]

btrfs na vrstvy nelze rozdělit

Všechno jde, jenom děti se musí nosit... Teda když se chce - a už jsem to psal, tady se nechtělo, protože by to znamenalo míň slávy a víc spolupráce s někým jiným.

[Heron]

Ale nenapsal jsi, jak by se dalo téhož dosáhnout při rozdělení na vrstvy (s využitím těch stávajících).

[Jendа]

Rád bych si poslechl především jak by řešil checksumy (nenapadá mě lepší řešení než jak to má AS/400, kde na disku jsou sektory velké 520B, přičemž 512 je normálně sektor a zbytek je checksum -- ty disky jsou pak skvěle kompatibilní se zbytkem světa) a snapshoty (tam zase znám na úrovni bloků jenom LVM, které je při víc snapshotech s víc změnami nepoužitelně pomalé).

[Heron]

Ona by se také docela špatně dělala ta základní funkcionalita.

Udělat blokové zařízení s podporou cow a snapshoty není až tak těžké. No ale co s tím? Když se nad tím udělá normální fs, tak dobře, můžu mít snapshoty (díky freeze i zcela konzistentní), ale co s nimi? Mít 10tis. připojených fs asi nejde. Nehledě na to, že to nebude umět ani reflinky (natožpak mezi subvolumy). Distribuce volného místa jde, fs bude reportovat (discard) volné bloky, což je ostatně nutné pro každý thin provisionning.

Dobře, máme lepší lvm a nějaký mountovací manager a umíme snapshoty. To je ale tak vše.

Jak vyřešit multidevice? Tak, abych mohl přidat disk libovolné velikost a aby se synchronizovaly jen zabrané bloky? Přes bitmapy?

Jako udělat to tak, aby tam ty vrstvy vidět byly jako nějak lze. Otázkou je, zda to k něčemu bude a otázkou je, zda je vůbec správné v první řadě to na ty vrstvy dělit (z hlediska vývoje úložných systémů to sice logiku mělo, ale otázkou je, zda není na čase to opustit).

[Ovocníček]

Nebylo to prostě tak, že byly OSu exponovány low-level sektory z HDD? Protože přímo na plotně v HDD samozřejmě sektor nemá těch 512 B, ale víc a jsou tam kontrolní součty (pomocí těch to taky ví, že při čtení nastala chyba). Jenom jsou používané interně a OS/FS to nevidí.

[Cohen]

Jenže data + checksum v jednom bloku neřeší všechno, co dokáže pokrýt Btrfs/ZFS s checksumy ukládanými odděleně od hlídaných dat. Jak zjistíme, že jsme přečetli sice nepoškozená data, ale ze špatného místa disku, tzn. něco jiného, než se mělo přečíst? Co se stane, pokud nějaký zápis na disk omylem a bez povšimnutí neprojde? Pak později přečteme z úložiště blok ze správného místa, checksum dat v něm bude i sedět, ale budou to nějaká jiná data, tj. původní obsah toho bloku, který jen omylem nebyl přepsán novými daty.

[Jendа]

Jak zjistíme, že jsme přečetli sice nepoškozená data, ale ze špatného místa disku, tzn. něco jiného, než se mělo přečíst?

Aha, tak už chápu, proč je tam 4 bajty checksum a 4 bajty číslo sektoru.

Co se stane, pokud nějaký zápis na disk omylem a bez povšimnutí neprojde?

Jo, to se nechytí.

[Aleš Kapica]

Pozor, problém není v Btrfs, ale v jaderném modulu, který s ním pracuje. Nejsem kernelový guru, abych dokázal určit příčinu, ale současná verze dokáže rozbít za určitých okolností i Btrfs v raid1. Podařilo se mi to souborem virtuálního disku v qed formátu, který byl do virtuálu zpropagován přes file. Vysvětluji si to tak, že Btrfs vně virtuálu ztratilo kontrolu nad obsahem extentu, do kterého se valily další a další data. Problém se týkal obou fyzických zařízení, na které se měl extent replikovat a pomohlo až nové vygenerování chsumů na obou fyzických discích, které se ovšem provádí na zařízeních, které nesmí být připojeny. Což v případě systémového disku znamenalo práci v ramdisku. Proto se snažím mít data u kterých může k takové situaci dojít na odděleném diskovém oddílu.

[Ovocníček]

Může to bejt víc věcí, včetně i té chyby na sběrnici. Viděl jsem jeden notebook, co na mass storage discích, jak klíčenkách, tak HDD dělal s poměrně velkou frekvencí potichu korupci dat. Někde asi překlopil nějaký bit, při kopírování velkých souborů se to stávalo tak s frekvencí jeden soubor z pěti. BTW CPU Intel, čipset Intel, údajně vždy stopro stabilní kombinace :)

[Miloslav Ponkrác]

To je lesk a bída současných počítačů.

1) Spolehlivost netrápí nikoho. Proto se také spolehlivost snižuje.

2) Poslední procesory jsou vyrobeny tak nízkými nanometry, že chyby v procesoru musejí nutně nastávat už z fyzikálních zákonů. Různé radioaktivní či nabité částice, které se vyskytují úplně všude (přirozené rádiové pozadí), mají zde zvýšený vliv. I z tohoto důvodu mám nejdůležitější počítače s 45 nm procesory.

3) MB a RAM paměti se pro běžné desktopy vyrábějí bez ECC – to by se lidé divili, kdyby ECC bylo!!! To by bylo smutku!!!

Kromě toho operační systém neumí na ECC chybu v RAM nijak vhodně zareagovat, pouze to celé shodí.

4) Architektura operačních systémů je také snaha „poručit větru dešti“ s tím, že se ignorují fyzikální zákony. Monolitický operační systém, který má kernel obsahující řádově 10 miliónů řádků zdrojového kódu, a který musí pro dobrý chod být bez chyby – fyzikální zákony naprosto vylučují to, že by zde chyba nebyla, přesněji, že by v kernelu nebyly obrovské mraky chyb. (To platí pro Linux i Windows.)

Původní unix princip byl: „mít malé a jednoduché jádro (do pár desítek tisíc řádků zdrojového kódu), které je dokonale odladěno a považováno za bezchybné“. Na tom to bylo postaveno, a to je v souladu s tím, co fyzikální zákony ještě reálně umožňují.

5) Lidi na úložných médiích zajímá jediné: kapacita a rychlost. Protože HDD a SSD si konkurují, oba druhy zkoušejí velmi experimentální metody uložení dat, jako jsou popsány v článku, zejména pro zvýšení kapacity.

Jakékoli novinky na HDD jsou nespolehlivé. SSD je nespolehlivé už z principu, a rok od roku je to horší. SSD je snad jediná technologie, která se s časem zhoršuje, klesá její životnost, spolehlivost, rychlost, zvyšuje se spotřeba (která už brzy předstihne spotřebu HDD a občas se tak už stalo).

Vlastně je smutné, že HDD s mechanickými částmi spolehlivostí skvěle konkuruje SSD bez jakýchkoli pohyblivých částí. Už to samo o sobě říká, že SSD je něco shnilého a nespolehlivého.

Nastal prostě trend shitových úložišť, kde jde především o kapacitu a levnou cenu. Spolehlivost nikdo neřeší. Dnešní SSD neudrží data, pokud rok nezapnete počítač či zařízení, kde ho máte. (Zdůrazňují dnešní, dnes koupená. Dříve to bylo lepší.)

6) Linux obsahuje miliardu filesystémů. Namísto toho, aby se vzaly jako základní jeden, možná dva, v nejhorší tři – ty se pořádně odladily, a vše ostatní bylo bráno jako nevýznamné. Upřímně, zde je strategie Microsoftu rozumnější: nerozmnožuje zbytečně filesystémy, a pořádně kartáčuje a vyvíjí NTFS.

Je jasné, že v těch driver filesystémů bude také mraky chyb.

7) Zálohu jsem vyřešil tak, že zálohuji komprimované balíčky ZIP/RAR/7Z, které samy o sobě obsahují kontrolní součty. Bez ohledu na filesystém tak mám kontrolu, zda je soubor v pořádku – a nemusím používat experimentální a potenciálně chybové filesystémy jako btrfs jen proto, že mají kontrolní součet.

Opět jsem zvolil antilinuxové řešení, neukládám tar + něco, ale obvykle zip či 7z, kde komprimovaný balík ví o souborech, které obsahuje, přímo, a také o nich má přímé informace a pracuje separátně s každým z nich zvlášť.

Kromě toho mám výhodu v komprimaci, mnohem lepší, než by dokázal jakýkoli zálohovací systém sám o sobě. Navíc větší soubory efektivněji využívají místa na disku. A pokud si navíc na zálohovacím médiu vytvoříte větší clustery, protože malé soubory neukládáte, zjendoduší se i struktura disku/filesystému a je to o krapítek spolehlivější a rychlejší.

8) Problém je, že spolehlivá záložní média nejsou. Trh je nepožaduje, navíc lidé mají na počítači většinu věcí, o které mohou bez problémů přijít. Trh požaduje vysoké kapacity a rychlé čtení.

Spolehlivost a údržnost dat na médiích nepožaduje nikdo.

[Aleš Kapica]

Pane, že jste svým způsobem blázen už nějaký čas víme, ale že to jde až daleko, to jsem netušil. Uvědomujete si, že nabourany archiv je větší průser než nabouraný FS, který byl navržen tak, aby ho bylo možné opravit?

[Miloslav Ponkrác]

Dobrá, budu s vámi diskutovat stejným způsobem, jako vy se mnou.

Že jste, pane Kapico, svým způsobem idiot, to už všichni vědí, ale uvědomujete si, že nabouraný filesystém nemusí být opravitelný stejně dobře jako archív?

Nebourat neopravitelně jde všechno. V tom případě je dobré vědět, zda jsou data v pořádku (kontrolní součet), nebo ne.

[Aleš Kapica]

Od toho je souborový systém, aby zachoval data v pořádku. Smysl komprimovaných archivů je poněkud jinde. Pokud použijete FS, který vám nezajistí konzistenci dát, tak zálohu z poškozeného archivu neobnovíte, ani kdyby jste se rozkrájel. Leda byste měl pro každý takový archív uloženy někde bokem opravné ecc kódy, o čemž silně pochybuji že máte. Ale vaše data, váš problém.

[Jendа]

Leda byste měl pro každý takový archív uloženy někde bokem opravné ecc kódy, o čemž silně pochybuji že máte.

par2 c archv.7z

[Jendа]

Pane, že jste svým způsobem blázen už nějaký čas víme, ale že to jde až daleko, to jsem netušil.

1-5 má pravdu

V 6) bych nesouhlasil, podle mě se většina práce koncentruje právě na ext a btrfs, tak jako kdyby jiné FS neexistovaly.

V 7) bych doporučil nemít jen kontrolní součty, ale rovnou samoopravné kódy. Například pomocí programu par2.

8) Kup si víc nespolehlivých.

Osobně mě štve, že SLC karty a SSDčka nestojí méně než 3x víc než TLC (jak by se řeklo logicky), ale 10x víc.

[Aleš Kapica]

Reagoval jsem především na bod 7. Už v několika jiných diskuzích p. Ponkrác ukázal že technologicky poněkud ustrnul - proto jsem si také neodpustil onu invektivu. Ovšem řešit problematiku fyzických blokovych zařízení a souborových systémů použitím komprimovaných archivů bez toho, že by k nim souběžně generoval opravné kódy, tak tím mne fakt dostal.

[Heron]

V 6) bych nesouhlasil, podle mě se většina práce koncentruje právě na ext a btrfs, tak jako kdyby jiné FS neexistovaly.

Docela se máklo na xfs a RedHat to má jako default (RHEL 7).

[peter]

Lepsie archivacne programy su urcene aj na zalohu dat a vedia pridat recovery info, co je v podstate parita, alebo treba pouzit par2.

[Kvakor]

To je lesk a bída současných počítačů. 4) Architektura operačních systémů je také snaha „poručit větru dešti“ s tím, že se ignorují fyzikální zákony. Monolitický operační systém, který má kernel obsahující řádově 10 miliónů řádků zdrojového kódu, a který musí pro dobrý chod být bez chyby – fyzikální zákony naprosto vylučují to, že by zde chyba nebyla, přesněji, že by v kernelu nebyly obrovské mraky chyb. (To platí pro Linux i Windows.)

Ha, kdyby jen fyzikální, to by ještě šlo řešit redundancí a vzájemnou kontrolou. Problém je v tom, že u netriviálních programů teoreticky vůbec nejde zjistit, jestli chyby obsahují nebo ne, viz problém zastavení. Sice je možné pokusit se o formální verifikaci, kdy se koreknost programu posuzuje pomocofí matematických metod, jenže bohužel je to zatraceně náročné (z toho důvodu se to dělá jen u věcí, kde se to opravdu vyplatí), zadruhé i samotná matematika má své limity, viz Gödelovy věty o neúplnosti (osobně si myslím, že existuje hluboké spojení těchto vět a výše zmíněného problému zastavení, možná dokonce i problému P versus NP).

[Heron]

Poslední procesory jsou vyrobeny tak nízkými nanometry

A proč zrovna 45nm? Proč ne stovky mikrometrů jako pro družice? Odkud se vzalo zrovna 45?

MB a RAM paměti se pro běžné desktopy vyrábějí bez ECC – to by se lidé divili, kdyby ECC bylo!!! To by bylo smutku!!!

Zkušenosti s něco přes 1TB RAM a 8 let běhu (jistě, velikost paměti postupně rostla) hovoří něco jiného. Opravitelné chyby ECC jsou velmi vzácné (na prstech jedné ruky do roka). Neopravitelnou jsem neviděl ani jednu. To už je častější, že odejde celý modul.

Když jsem doma viděl detekovanou ECC v L3 CPU, tak to byl svátek. Zatím jen jednou (a to se v té paměti motá víc dat vyšší rychlostí, než v systémové ram).

Architektura operačních systémů je také snaha „poručit větru dešti“ s tím, že se ignorují fyzikální zákony.

Jasně. Jinak chtěl bych vidět někoho, kdo reálně využívá celé jádro. To, že je to monolit nic neznamená, jelikož nikdo nemá zavedené všechny moduly a ani omylem nepoužívá vše, co jádro v celku nabízí. Jednotlivé běhy budou využívat jen zlomek z celkového kódu (a to navíc ještě tu nejpoužívanější a nejotestovanější část).

Lidi na úložných médiích zajímá jediné

To se možná týká disků pro spotřebu, ale ne pro DC.

ty se pořádně odladily

Co to konkrétně znamená pořádně odladit fs? Všechny používané fs jsou po implementační stránce odladěné.

Další a zásadnější problém je s požadavkem na jeden fs. Žádný FS nemůže z principu vyhovovat všem situacím, všem pracovním zátěžím. Některé požadavky jdou přímo proti sobě. Jde to vidět i na NTFS, na nějaký průměrný případ průměrného desktopu je připraven dobře. To jo. Ale všude jinde je to katastrofa, stejně jako by to byla katastrofa pro kterýkoliv jiný fs mimo jeho sweet point. Toto je důvod, proč mít víc fs. Aby bylo z čeho vybírat pro danou konkrétní situaci.

Zálohu jsem vyřešil tak, že zálohuji komprimované balíčky ZIP/RAR/7Z, které samy o sobě obsahují kontrolní součty.

Gratulujeme. Pořád používají CRC32 na celý soubor? Úžasné. V BTRFS je to na každý 4kiB blok. Zatím CRC32, místo je až na 256b a prostor pro jiné funkce. Bokem mám navíc i sha512 sumy celých souborů (to jsem původně začal používat už dřív pro detekci silent data corruption na disku, za hromadu let ani jeden problém).

Problém je, že spolehlivá záložní média nejsou.

Jsou. Otázkou je, nakolik se vyplatí do nich investovat (= jak drahá data potřebujeme zálohovat).

[Jendа]

A proč zrovna 45nm? Proč ne stovky mikrometrů jako pro družice? Odkud se vzalo zrovna 45?

Protože stovky mikrometrů mělo naposledy originální Pentium a 22 let staré procesory už se blbě shání a provozují?

Jde to vidět i na NTFS

Už se vlastně Windows naučily dělat ekvivalent MD RAIDu, LVM a snapshotů?

[Ovocníček]

"Stovky" jsou přesně co? Pentia III s taktem 550 MHz ještě byla 250nm (shánět jádro Katmai), také první Ahtlony K7 s podobnými takty byly 250nm. Na 180 nm byly Athlony XP s taktem IIRC okolo 1,6 - 1,7 GHz, a Pentia 4 (ale ta moc dobrá nebyla, IIRC). na 130 nm se dají mít kromě slušných Pentií 4 Northwood s takty po 3,něco GHz také Athlony 64 a Opterony.

Jinak je to samozřejmě blbost. Nebo minimálně pomýlené obsedantní lpění na nevýznamném detailu, když drtivá většina nestabilit a nehod se stane z jiným příčin.

--------------------------------------

Před pár lety Windows dostaly něco nazvané Storage Spaces a ReFS, ale jsem línej si k tomu zjišŤovat víc, většina infa, kterou k tomu dává Google, je stará 3 roky (z doby vydání W8).

[Jendа]

Jo, blbě jsem si ta čísla pamatoval.

[sigma]

Už se vlastně Windows naučily dělat ekvivalent MD RAIDu, LVM a snapshotů?

Minimálně u snapshotů je situace snad i lepší než na linuxu. VSS (Volume Shadow Copy) je k dispozici od Win XP / Server 2003. Jsou to snapshoty na úrovni FS se všemi výhodami s tím spojenými. Tj. něco, co v linuxu "máme" až s Btrfs. LVM snaphoty se tomu fakt neblíží.

Snapshoty mají i GUI integraci (předchozí verze souborů), což navíc nativně funguje i přes síť (k tomu lze tedy donutit i Sambu nad ZFS nebo Btrfs).

Kromě toho ACL systém na NTFS je rozhodně mocnější než POSIX ACLs, u kterých už jsem sám na limity několikrát narazil. Situace se srovnatelnými nfsv4 ACL je v linuxu hodně smutná...

MD RAIDu a LVM odpovídají tzv. dynamické disky (Dynamic Disks and Volumes, https://technet.microsoft.com/en-us/library/cc737048(v=ws.10).aspx) - k dispozici od Win 2000. Dříve tam byla nějaká omezení při provozu v clusteru nad SAN, a bylo třeba používat místo toho např. Veritas Volume Manager, aktuální stav už moc neznám.

[Max]

Tak tak, souhlas. Jinak také mi z části přišla snapshotovací fce VSS ve windows lepší, jak v linuxu. Jde o to, že ve win s tím každá app počítá. Když se tedy provede VSS, tak všechny služby flushnou data (Exchange, MSSQL apod.) a docílí se tak i plně konzistentní zálohy. V linuxu si to člověk musí řešit "ručně", tzn. před vytvořením snapshotu je třeba říci všem běžícím app, aby flushly data na disk.
Jinak jak už bylo řečeno, Dynamic Disks je něco jako LVM a MD, ale né tak propracovaný. Umí to základy, nic pokročilejšího, ale zato je to plně klikací.
VSS je také dobré pro file share, kde se dá naklikat vytváření VSS třeba každou hodinu, čímž se tvoří historie souboru/dat a lze tak data obnovit po velmi krátkých časových intervalech.
Zdar Max
PS: Nedávno mi jeden SBS2008 padal vždy v celou, ale náhodnou hodinu. Problém byl nejspíše v tom, že se dělal často VSS, pole mělo větší latence, na onom oddílu byl pagefile (swap file). Po přesunutí pagefile na oddíl, kde je VSS vypnuté server běží bez výpadku.

[Chulda]

No, to VSS zas tak mocné není. Nezjišťoval jsem design/implementaci VSS, ale co se stane, když to aplikace do nějaké doby nestihne?

Pod vmware je občas tuna chyb ve windows, které jsou obzvláště roztomilé, viz KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007696 nebo http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2006849

Nejraději mám tu chybovou hlášku s ID 157 "Disk x has been surprise removed.", ale je to jen warning

[Heron]

Protože stovky mikrometrů mělo naposledy originální Pentium a 22 let staré procesory už se blbě shání a provozují?

Neplést si mikro a nano . Plácl jsem schválně stovky mikrometrů a upřímně ani nevím, jestli někdy byl cpu takhle velkou planární metodou vyroben (asi ne).

Jinak, on má někdo skutečný problém s velikostí dnešních tranzistorů v cpu? Jak se to projevuje?

[Ovocníček]

Protože stovky mikrometrů mělo naposledy originální Pentium a 22 let staré procesory už se blbě shání a provozují?

Neplést si mikro a nano . Plácl jsem schválně stovky mikrometrů a upřímně ani nevím, jestli někdy byl cpu takhle velkou planární metodou vyroben (asi ne).

A jo, to jsem si nevšim. Stovky mikrometrů asi fakt ne. Si mě splet tím Pentiem, prototože to IIRC bylo tak na 800 - 500 nm (hmm, wikipedia říká že 0.8 µm až 0.25 µm u nějakých pozdních mobilních verzí, mainstream skončil na 350nm, kde začalo Pentium II).

U Intelu 8080 byla "minimum feature size" 6 µm, u 4004 10 µm. Takže asi tak. Ono taky co je stovka mikrometrů, že jo? To by se toho na wafer moc nevešlo.

Jinak, on má někdo skutečný problém s velikostí dnešních tranzistorů v cpu? Jak se to projevuje?

Myslím že nemá a nijak :) Řeší to samozřejmě výrobci čipů, protože musí víc bojovat s úniky proudu a je to těžší vyrobit, ale nám plebsu to může být jedno, i když možná někdo má iluze vlastní důležitosti a říká si, že on přece potřebuje něco lepšího.

[Heron]

Si mě splet tím Pentiem

Pentium plácl Jenda, já nic, já muzikant

Myslím že nemá a nijak :) Řeší to samozřejmě výrobci čipů, protože musí víc bojovat s úniky proudu a je to těžší vyrobit, ale nám plebsu to může být jedno, i když možná někdo má iluze vlastní důležitosti a říká si, že on přece potřebuje něco lepšího.

Asi tak.

[Ovocníček]

Sorry! Holt problém udržet pozornost, prostě, no...

[Heron]

Moc ovoce, to chce maso

[Odin1918]

Různé radioaktivní či nabité částice, které se vyskytují úplně všude

Kristalova koule patrne emituje mnozstvi osklivych castic. Doporucuji poridit dostatecne silnou olovenou krabicku, do ktere budete kouli pred zapnutim pocitace vkladat. Timto resenim se dostanete klidne na 14 nm.

[Tomáš Bžatek]

Pekny clanek a zjisteni.

FYI, WD heliove disky nevyrabi, vsechna slava jde na vrub nedavno plne spolknute HGST. A stejne tak Seagate pred casem pohltil diskovou divizi Samsungu, takze honit se za znackou nema v dnesni dobe moc smysl. Jen je potreba si davat bacha

[Cohen]

Jsem neustále ve skluzu ve čtení RSS, takže jsem k tomu došel proklikem až dnes ráno v šalině – tak HGST už má i heliem plněné 10 TB, ale ty už navíc používají taky SMR. :-/

[Cohen]

Tak Seagate už se taky uchýlil i k použití helia.

[Cohen]

Seagate je teď dokonce kvůli údajné přílišné nespolehlivosti svých disků žalován.

[Sten]

Ze zkušenosti: btrfs balance nad hodně používaným RAIDem 10 občas deadlockuje. Nepodařilo se mi to ale debugovat, ale stávalo se mi to, jen pokud jsem použil víc než 4 disky.

[kralyk z abclinuxu]

Stručný závěr: Btrfs ještě chce nějaký vývoj, ale už teď vážně zvažte jeho použití

Už teď? Po 6 letech vývoje? No, sice se tomu směju, ale ono je to reálně spíš smutné, btrfs by mělo být vlajkovou lodí, ale moc to tak zatím nevypadá.

Cool fíčury jako checksums, snapshoty, subvolumes atd. sice vypadají lákavě, ale pokud FS nemá robustnost, tak nemá nic. V tomhle ohledu imho není nad XFS, spolehlivější a odolnější FS neznám.

Kdybych jó chtěl tyhle pokročilý featury, tak bych spíš koukl po ZFS.

Mimochodem, nedávno se mi na androidím telefonu nějak záhadně pokazil F2FS, takže tomu už taky nevěřim...

[Heron]

Už teď? Po 6 letech vývoje? No, sice se tomu směju, ale ono je to reálně spíš smutné, btrfs by mělo být vlajkovou lodí, ale moc to tak zatím nevypadá.

Já používám btrfs pátým rokem. Nevím, proč by mělo být k smíchu, že někdo něco doporučuje po 6 letech vývoje, přičemž:

imho není nad XFS

FS z roku 1993, na linux portovaný 2001. Tedy 22 od narození, 14 let od portace. Pořád ještě je těch 6 let k smíchu?

[kralyk z abclinuxu]

Ale jo, chápu, že to trvá dlouho, spíš mě ale není úplně sympatický ten přístup - přijde mi, že featury mají přednost před robustností... Možná to je jen dojem.

[Cohen]

Cool fíčury jako checksums, snapshoty, subvolumes atd. sice vypadají lákavě, ale pokud FS nemá robustnost, tak nemá nic. V tomhle ohledu imho není nad XFS, spolehlivější a odolnější FS neznám.

Pokud chce člověk pod Linuxem stabilní otestovaný filesystém, má Ext*/XFS. Jenže to nyní přestává stačit, takže bez těch cool features by Btrfs neměl smysl (nabízel by jen větší nestabilitu bez jakékoliv přidané hodnoty oproti uvedeným filesystémům). Smysl nového filesystému je právě v tom, že bude umět nové kousky. Že odladění a prověření časem a reálným provozem trvá dlouho, to je realita současného vývoje software, která u souborových systémů platí dvojnásob (i když by se mi také líbilo, pokud by stabilizace a vývoj Btrfs šel rychleji).

Kdybych jó chtěl tyhle pokročilý featury, tak bych spíš koukl po ZFS.

Jenže Btrfs má pod Linuxem docela výraznou výhodu ve standardní integraci – je to GPL kód v jádře. ZFS z licenčních důvodů takto pěkně fungovat nemůže, navíc do Linuxu „nezapadá“ – pokud vím, tak se ZFS není dobře integrovatelný s VFS, ZFS svazek se pod Linuxem nedá připojit klasicky přes mount, ale musí se používat jedna ze ZFS obslužných utilit (pokud si toto myslím špatně, prosím o opravu, nejsem si tím 100% jistý). A nakonec Btrfs má oproti ZFS i některé návrhové výhody (bohužel se mi nedaří dohledat, kde jsem četl takový pěkný seznam funkcí, které Btrfs má a ZFS ne a popis toho, jak ZFS designově vychází ze správy dat v paměti, což vede k některým nevýhodám, např. problémů při odebírání zařízení, které se jednou začalo používat apod. ).

To ale samozřejmě nic nemění na tom, že ZFS je v reálném světě výrazně odladěnější a otestovanější, takže bych se ZFS pod Linuxem asi neměl větší problém ani pro opravdové produkční nasazení (i když...), kdežto u Btrfs bych se toho zatím stále bál, jak jsem nakonec zdůvodnil v původním zápisku.

[Heron]

ZFS není dobře integrovatelný s VFS

Tady má BTRFS taky škraloup:

Pokud přečtete velký soubor, tak při druhém čtení už je celý v iocache (pokud se tam vleze) a je to maximálně rychlé.

Jenže, pokud uděláte snapshot dané subvolume a čtete stejný soubor na tom snapshotu, tak se opět čte z disku, i když to jsou stejné bloky. Takže tentýž soubor skončí v iocache podruhé.

Opakovné čtení souboru na subvolume test ("zdrojové"):

dd if=test/file of=/dev/null bs=1M
4474+1 records in
4474+1 records out
4692282082 bytes (4.7 GB) copied, 0.737969 s, 6.4 GB/s

Po snapshotu (subvolume test na subvolume test1) :

btrfs sub snap test test1
Create a snapshot of 'test' in './test1'

První čtení z této test1 subvolume ("cílové"):

dd if=test1/file of=/dev/null bs=1M
4474+1 records in
4474+1 records out
4692282082 bytes (4.7 GB) copied, 10.1259 s, 463 MB/s

Další čtení:

dd if=test1/file of=/dev/null bs=1M
4474+1 records in
4474+1 records out
4692282082 bytes (4.7 GB) copied, 0.73834 s, 6.4 GB/s

Toto není problém při běžném použití, ale pokud se čte napříč snapshoty, které vznikly z jedné subvolume (a tedy obsahují většinou shodná data a odkazy na stejné bloky), tak se zbytečně čtou tytéž bloky stále dokola.

[Cohen]

A nakonec Btrfs má oproti ZFS i některé návrhové výhody (bohužel se mi nedaří dohledat, kde jsem četl takový pěkný seznam funkcí, které Btrfs má a ZFS ne a popis toho, jak ZFS designově vychází ze správy dat v paměti, což vede k některým nevýhodám, např. problémů při odebírání zařízení, které se jednou začalo používat apod. ).

Dneska jsem na to náhodou asi znovu narazil. Myslím, že jsem měl na mysli toto: A short history of btrfs [LWN.net]

[Jendа]

Kdybych jó chtěl tyhle pokročilý featury, tak bych spíš koukl po ZFS.

U ZFS mě štvalo, že nejdou do zpoolu dávat různě velká zařízení, ani vlastně nejde dynamicky zmenšovat (nevím jestli jde vůbec zvětšovat).

[Cohen]

BTW, dnes jsem se pročetl k tomu, že nadcházející LTS Ubuntu 16.04 asi bude umět instalovat kompletní systém na ZFS. Jsem docela zvědavý, jak to bude integrované.

[kolcon]

...xfs, pokud vam teda obcas nevadi soubor plny nul (osobni zkusenost po vypadku napajeni)

[tom62]

Mám bohužel podobnou zkušenost (nevím, zda tam byly nuly, ale původní obsah rozhodně ne). Měl jsem jeden počítač, u kterého tvrdé restarty byly z nejrůznějších důvodů poměrně časté, zkoušel jsem XFS, ReiserFS a Ext4 a jediný posledně jmenovaný se mi nikdy nerozsypal (ale může jít o náhodu).

[Filip Jirsák]

To byla vlastnost XFS. Před X lety. Dneska už se tak XFS nechová.

[H0ax]

Moje zkušenost cca 2r zpět - 2T svazek raid1, xfs, po restartu nenajel, fsck fs opravil tak, že mi sesypal všechny soubory na hromadu, místo názvů udělal čísla a samozřejmě odstranil koncovky. To je mi pak jedno, že ta data mám, když vím prd, co jsou zač a kde původně byla. Tou robustností si u xfs teda jist nejsem. Co se mi hodně líbí je dir quota, to nic jinýho nemá.

[Aleš Kapica]

Co se mi hodně líbí je dir quota, to nic jinýho nemá.

Ale má - Btrfs.

[H0ax]

V btrfs holt ještě nemám tu důvěru nicméně ty quoty testnu, díky.

[Bedňa]

Keď už chcem vážne dáta mať niekde uložené, stále aj po rokoch víťazí ReiserFS. Za roky jediný FS kde sa mi nič nestratilo ani pri zlyhaní HW.

[BLEK.]

Já žádná data nemám, protože trpím poruchou osobnosti (byla mi diagnostikována psycholožkou). Myslím, že pan Reiser také trpí nějakou poruchou, protože zabil svou ženu (možná neuměla plavat a jemu to vadilo), teď je ve vězení a vývoj ReiserFS pokulhává. Reiser4 stále není v kernel mainline.

[Aleš Kapica]

Reiser4 je v kopru a navíc dávno překonaný.

[Bedňa]

Heh, heh, heh a čím?

[Aleš Kapica]

Jen pro informaci všech přítomných. Btrfs má v současném stable řadě jádra 4.3 bugy, které řeší patche, co jsou zařazeny až do jádra 4.4, takže i když ještě není stabilizované ( zatím je venu 4.4-rc8 ), tak se asi - pokud Btrfs používáte a můžete si to dovolit - aktualizace vyplatí.

Ty chyby jsou totiž dost nepříjemné - především v tom, nemusí jít dodatečně opravit. Při běžném provozu na ně nejspíš nenarazíte, ale pokud používáte virtualizaci a velké virtuální disky tak ano.

[Cohen]

A nějak konkretizovat by to šlo? Tj. kterých z těch mnoha bugů se máme nyní konkrétně bát?

[Aleš Kapica]

Podle kolegy Pavla za chybou na kterou jsem narazil já, vězí kód, který opravuje tento patch:

commit bb1591b4ea1a1485ebc79be4e4748e94f96c670b