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

28.12.2015 11:22 | Přečteno: 3916× | Btrfs | | poslední úprava: 7.6.2016 22:55

Jsem velký fanda Btrfs a nedávno jsem psal o tom, jak jsem jej nasadil i na jednom ne až tak důležitém produkčním serveru, když jsem narazil na omezení velikosti Ext4 filesystému. Od té doby mám s Btrfs (a moderními spotřebitelskými disky) dva zážitky, které se dají shrnout jako lesk a bída Btrfs a bída moderních pevných disků. Stručný závěr: Btrfs ještě chce nějaký vývoj, ale už teď vážně zvažte jeho použití, protože kontrolní součty na úrovní filesystému jsou strašně důležitá a užitečná vlastnost a moderním diskům se nedá věřit.

Poznámka 2016-06-07: SMR disky jsou ještě větší nářez, než jsem si původně myslel.

Bída Btrfs

Začněme tím ošklivým – jak jsem s Btrfs drobně narazil na onom serveru. Do ruky se mi dostaly další tři staré disky, které jsem do serveru mohl přidat a využít tak všechny diskové pozice, které v serveru jsou. Přidání zařízení do filesystému přes btrfs device add opět proběhlo bez problémů, stejně tak se bez problémů spustila balance operace, aby se nové disky začaly používat. Jak je u Btrfs dobrým zvykem, obě operace se provádí na připojeném filesystému, který je možné normálně používat. V době běhu této operace běžel na úložiště rsync většího množství dat z jiného stroje a běžela tam i lokální výpočetní úloha, která úložiště používala.

Po pár hodinách se ale stalo, že jsem se na server nedokázal připojit přes SSH. Na ping server odpovídal, ale připojení přes SSH se nezdařilo, stejně tak přestaly reagovat na serveru běžící webové služby od okamžiku, kdy měly začít pracovat s nějakými daty z toho Btrfs úložiště.

Nezbyla jiná možnost, než vyrazit do serverovny, připojit k serveru monitor a klávesnici a podívat se, co se děje. Ukázalo se, že server je v tak špatném stavu, že nedetekoval a nezpřístupnil ani USB klávesnici, kterou jsem k němu připojil. Na připojeném monitoru jsem tak viděl jen to, co šlo na konzolu:

Server jsem tedy musel natvrdo restartovat hardwarovým reset tlačítkem. Pak server bez jakéhokoliv problému naběhl, Btrfs úložiště připojil a od té doby bez problémů funguje.

Bohužel k tomuto nemám nic více, než tu fotku konzoly s chybovou hláškou. Snad to byla nějaká výjimečná anomálie. Ale vzhledem k tomu, že v té době server běžel na skoro nejnovějším jádře (konkrétně debianí 4.2.6, jestli se nepletu, které je pro použitý stabilní Debian 8 dostupné v backports), tak pro opravdu produkční nasazení bych se Btrfs asi přece jen ještě bál. :-/

Lesk Btrfs a bída moderních pevných disků

I přes výše uvedené si ale myslím, že je nanejvýš vhodné o nasazení Btrfs uvažovat, kdekoliv je to možné, protože jsem si před pár hodinami na vlastní kůži vyzkoušel, jak to vypadá, když průběžná kontrola všech zpracovávaných dat na Btrfs souborovém systému odhalí chybu v datech přečtených z disku, i když se disk tváří, že je všechno v nejlepším pořádku.

Začnu úkrokem stranou a krátce se zmíním o onom pevném disku. Zálohuji (mimo jiné) na externí disk, který je fyzicky připojen k počítači a elektrickému napájení jen v době, kdy se na něj zálohuje. Snažím se tak zabránit tomu, že bych přišel o zálohy v případě přepětí v elektrické síti, řáděním nějakého malware na téma CryptoLocker, chybou v nějakém skriptu nebo v jádře, která by ničila data na připojených discích apod.

Dřív jsem používal 3,5" disk v externím boxu, což znamenalo externí napájecí adaptér. Pak ale zvítězila lenost a přešel jsem na 2,5" externí disk, který je výrazně menší a navíc si vystačí s napájením z USB 3.0 portu, takže odpadá i otravný napájecí adaptér. Jenže dat je hodně (pravidelně zálohuji i obrazy systémových disků několika strojů pomocí nástroje Clonezilla), takže jsem potřeboval alespoň 4 TB disk. Ve 2,5" provedení je nabídka takto velkých disků zatraceně malá, takže jsem sáhl po disku Samsung M3 Portable 4 TB.

Bída moderních pevných disků

Jak asi tušíte, tak uvnitř není disk od Samsungu, ale od Seagate (konkrétně to vypadá na ST4000LM016-1N2170), což vzhledem k dlouhodobým statistikám spolehlivosti disků různých značek není žádná výhra (z poslední doby mne napadá např. toto, ale podobných statistik jsem viděl více). Co je horší, tak aby bylo možné do 2,5" disku běžné výšky natlačit 4TB kapacitu, tak disk dle všeho používá technologii Shingled Magnetic Recording (SMR), což je jedna ze zoufalých berliček, kterými se výrobci disků snaží udržet růst kapacit pevných disků, ale má nepříjemné vedlejší efekty – magnetické stopy se překrývají, takže při zápisu je třeba přečíst a znovu zapsat i vedlejší stopy, takže zápis na SMR disk je citelně pomalejší. Pokud vím, tak Seagate dokonce vyvíjí speciální podporu pro jádro, které má zajistit vhodnější zacházení se SMR disky.

Obecně mám pocit, že vývoj pevných disků je docela v křeči, navyšování kapacit se značně zpomalilo a používají se dle mého docela experimentální technologie s diskutabilní spolehlivostí. S dlouho slibovaným HAMR má Seagete stále problémy, Hitachi sice má na trhu velkokapacitní héliem plné disky, ale až čas ukáže, jestli plyn nebude z disků časem unikat a disky nebudou odcházet. Podobně je na tom Western Digital s héliem plněnými Perpendicular Magnetic Recording (PMR) disky.

A SSD? To je zase jiná pohádka. Odkaz už jsem nedohledal, ale z poslední doby si pamatuji např. na datasheet jednoho nového enterprise SSD tuším od Toshiby, kde bylo napsáno, že bez napájení je udržení dat garantováno po 4 měsíce (ne roky, měsíce). Problémů by se ale samozřejmě našlo výrazně více, o tom se tu ale rozepisovat nechci.

Shrnuto: V moderních pevných discích se používá spousta nových, málo vyzkoušených technologií s reálnými nebo potenciálními nepříjemnými vedlejšími efekty a kapacity disků jsou tlačeny zcela na hranice současných technických možností. Spolehlivost disků je tedy docela diskutabilní a vývoj do budoucna nejistý.

Samsung M3 Portable 4 TB – problémy s komunikací pod Linuxem

Aby toho nebylo málo, ukázalo se, že různé ASMedia USB-SATA můstky, což je chip použitý i v mém Samsung M3 Portable, mají pod Linuxem docela běžně problémy s komunikací v UAS režimu. Když jsem tedy disk Samsung M3 Portable začal používat, tak se v message bufferu jádra začaly při komunikaci s diskem objevovat hlášky typu:

[   99.882593] sd 6:0:0:0: [sdd] tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD 
[   99.882596] sd 6:0:0:0: [sdd] tag#8 CDB: Write(16) 8a 00 00 00 00 00 cd 00 fb d0 00 00 00 f0 00 00
[   99.882667] scsi host6: uas_eh_bus_reset_handler start
[   99.994700] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd
[  100.015613] scsi host6: uas_eh_bus_reset_handler success

Důsledkem zejména byla ještě výrazně pomalejší komunikace s diskem, než by bylo zdrávo, protože bylo potřeba každou chvíli čekat na restartování komunikace. Z diskusí na webu jsem navíc vyčetl, že se občas restart vůbec nemusí podařit.

Naštěstí řešení není až tak složité, jen je otravné – stačí bootovat s parametrem jádra usb-storage.quirks=04e8:61b7:u, což zakazuje použití UAS režimu pro USB zařízení identifikované kódem výrobce a modelu USB zařízení 04e8:61b7 (tohle ID se dá zjistit např. přes utilitu lsusb). Teoreticky by mělo být možné toto přidat jen do konfigurace jaderných modulů, to mi ale nefungovalo a bylo nutné parametr jádru nastavit už v konfiguraci Grubu.

Lesk Btrfs

Když už jsem migroval z jednoho externího disku na druhý, tak jsem zároveň přešel ze zálohování pomocí rdiff-backup na Ext4 oddíl na zálohování na Btrfs s historií záloh uchovávanou pomocí Btrfs snapshotů. Když jsem nový 2,5" externí disk začal používat, jednoduše jsem na něj na Btrfs zkopíroval data z původního disku, vytvořil první snapshot, a dále pravidelně zálohoval a vytvářel další snapshoty. Vše přitom vždy prošlo bez chyby.

Před pár dny už byl tento disk v provozu několik měsíců a já se konečně dokopal k tomu, že jsem na něm pustil „překartáčování“ Btrfs svazku. Neočekával jsem, že by mohly být nalezeny jakékoliv problémy. Byl jsem tak docela v šoku, když jsem uviděl výsledek:

$ btrfs scrub status /mnt/dataWarehouse/
scrub status for 57e00e5a-8de8-4d71-916d-feb61097328f
	scrub resumed at Sat Dec 26 20:54:03 2015 and finished after 08:01:19
	total bytes scrubbed: 2.73TiB with 5 errors
	error details: csum=5
	corrected errors: 0, uncorrectable errors: 5, unverified errors: 0
$ btrfs scrub status -R /mnt/dataWarehouse/
scrub status for 57e00e5a-8de8-4d71-916d-feb61097328f
	scrub resumed at Sat Dec 26 20:54:03 2015 and finished after 08:01:19
	data_extents_scrubbed: 45924933
	tree_extents_scrubbed: 476925
	data_bytes_scrubbed: 2999592312832
	tree_bytes_scrubbed: 7813939200
	read_errors: 0
	csum_errors: 5
	verify_errors: 0
	no_csum: 167904
	csum_discards: 0
	super_errors: 0
	malloc_errors: 0
	uncorrectable_errors: 5
	unverified_errors: 0
	corrected_errors: 0
	last_physical: 3714711420928

Průšvih, na disku bylo nalezeno 5 neopravitelných chyb! (Protože Btrfs užívá jediný disk, není tam žádná forma redundance dat, aby bylo možné přečíst dobrou kopii a chybu automaticky vyřešit.) Co je poškozené jsem zjistil z messages bufferu jádra, kam Btrfs scrub operace zapíše i cestu k postiženému souboru:

$ dmesg -H | grep -i 'btrfs'
[Dec27 01:02] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 4279, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000025] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3877, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.021036] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3815, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.040838] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3752, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.012128] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3688, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.006740] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3627, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.011365] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3568, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.007758] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3507, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.003485] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3499, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.010857] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3434, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.004488] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3371, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.021104] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3158, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000026] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3148, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 3113, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196767744 on dev /dev/sdj1, sector 3519067784, root 271, inode 2922, offset 1059917824, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000005] BTRFS: bdev /dev/sdj1 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0
[  +0.000003] BTRFS: unable to fixup (regular) error at logical 1808196767744 on dev /dev/sdj1
[  +0.038153] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 4279, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000020] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3877, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3815, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3752, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000036] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3688, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000018] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3627, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3568, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3507, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3499, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3434, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3371, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3158, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000019] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3148, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 3113, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000020] BTRFS: checksum error at logical 1808196771840 on dev /dev/sdj1, sector 3519067792, root 271, inode 2922, offset 1059921920, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000005] BTRFS: bdev /dev/sdj1 errs: wr 0, rd 0, flush 0, corrupt 2, gen 0
[  +0.000002] BTRFS: unable to fixup (regular) error at logical 1808196771840 on dev /dev/sdj1
[  +0.000459] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 4279, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000021] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3877, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3815, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3752, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3688, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3627, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3568, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3507, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3499, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3434, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000018] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3371, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3158, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000018] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3148, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 3113, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196775936 on dev /dev/sdj1, sector 3519067800, root 271, inode 2922, offset 1059926016, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000010] BTRFS: bdev /dev/sdj1 errs: wr 0, rd 0, flush 0, corrupt 3, gen 0
[  +0.000002] BTRFS: unable to fixup (regular) error at logical 1808196775936 on dev /dev/sdj1
[  +0.000380] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 4279, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000019] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3877, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3815, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3752, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3688, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3627, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000015] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3568, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3507, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3499, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000015] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3434, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3371, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000023] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3158, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3148, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 3113, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000015] BTRFS: checksum error at logical 1808196780032 on dev /dev/sdj1, sector 3519067808, root 271, inode 2922, offset 1059930112, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000005] BTRFS: bdev /dev/sdj1 errs: wr 0, rd 0, flush 0, corrupt 4, gen 0
[  +0.000002] BTRFS: unable to fixup (regular) error at logical 1808196780032 on dev /dev/sdj1
[  +0.000404] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 4279, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000019] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3877, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3815, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3752, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3688, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3627, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3568, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3507, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3499, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000015] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3434, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3371, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3158, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000017] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3148, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000016] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 3113, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000015] BTRFS: checksum error at logical 1808196784128 on dev /dev/sdj1, sector 3519067816, root 271, inode 2922, offset 1059934208, length 4096, links 1 (path: Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4)
[  +0.000004] BTRFS: bdev /dev/sdj1 errs: wr 0, rd 0, flush 0, corrupt 5, gen 0
[  +0.000002] BTRFS: unable to fixup (regular) error at logical 1808196784128 on dev /dev/sdj1

Odnesl to tedy soubor Trabantem Jižní Amerikou/Trabantem Jižní Amerikou - 06. díl - Kam vyjede trabant.mp4, tedy televizní nahrávka jednoho dílu skvělého seriálu Trabantem Jižní Amerikou od Dana Přibáně a jeho party z prodloužené verze dokumentu od České televize.

V archivu nahrávek jsem si už kdysi dávno (a teď jsem za to zpětně strašně rád) začal s každým novým souborem vždy ukládat i jeho SHA-256 kontrolní součet. Když jsem SHA-256 kontrolní součet ověřil na primární kopii dat na zdrojovém disku, seděl. Ostrá kopie tedy je v pořádku. Když jsem zkusil ověřit SHA-256 kontrolní součet na kopii na externím disku, skončilo to vstupně výstupní chybou sha256sum a v messages bufferu jádra se objevilo hlášení:

[Dec27 01:47] BTRFS warning (device sdj1): csum failed ino 2922 off 1059917824 csum 2014187447 expected csum 1349536242
[  +0.043640] BTRFS warning (device sdj1): csum failed ino 2922 off 1059917824 csum 2014187447 expected csum 1349536242
[  +0.010985] BTRFS warning (device sdj1): csum failed ino 2922 off 1059917824 csum 2014187447 expected csum 1349536242
[  +0.000377] BTRFS warning (device sdj1): csum failed ino 2922 off 1059917824 csum 2014187447 expected csum 1349536242

Btrfs tedy detekoval chybná data přečtená z pevného disku, data dále nepustil a jen ohlásil chybu, protože neměl jinou kopii, ze které by chybu automaticky vyřešil. (Mimochodem je ale nepříjemné, že při běžném čtení/zápisu dat už se člověk z chybového hlášení v logu nedozví, o jaký soubor jde, to je jen součástí hlášení ze scrub operace.)

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í! Respektive je to jedna z možností. Otázkou za sto bodů totiž je, jak tato chyba vznikla. Napadá mne několik možností:

1. Chyba je v Btrfs – Data byla na disk zapsána v pořádku a následně byla z disku i zcela správně přečtena, ale Btrfs chybně vypočítal/ověřil/uložil/přečetl/spároval datový blok a jeho kontrolní součet. Chyba tedy není v datech, ale jejich interpretaci jádrem.
2. Chyba v datech vznikla před zápisem na disk v registru procesoru / operační paměti / na sběrnici apod. – Použitý počítač je běžný desktop bez hardwarové kontroly ECC na operační paměti. Teoreticky jsem tak asi mohl mít smůlu a nějaká ta kosmická částice mohla trefit příslušnou paměťovou buňku v RAMce nebo někde tak nešťastně, že data a odpovídající kontrolní součet sice byla vytvořená správně, na disk už ale šla data poškozená.
3. Chyba je/byla v komunikaci s diskem – Vzhledem k výše uvedeným problémů s UAS komunikací, kterou jsem odhalil a obešel až nějakou dobu po tom, co už jsem disk používal, napadá mne, jestli při zápisu tohoto souboru nedošlo k nějakému ne zcela povedenému restartu komunikace s diskem, který měl za následek uložení poškozených dat na disk.
4. Chybná data vracená pevným diskem – Data a kontrolní součet byl vypočtený a na disk zapsaný správně, ale nyní disk bez jakéhokoliv varování vrací poškozená data.

Nepředpokládám, že by k chybě mělo dojít při čtení z původního externího disku při migraci na nový disk. Pokud by byla přečtena poškozená data bez indikace chyby, tak by se to operační systém nedozvěděl a vypočítal a uložil by korektní kontrolní součet pro tuhle chybnou verzi dat. Nedošlo by tedy k rozporu mezi daty (byť na významové úrovni poškozenými) a jejich kontrolním součtem (ten by byl vytvořen správně pro tato významově chybná data). Z uvedených možností také považuji za hodně nepravděpodobnou možnost č. 2.

U ostatních variant těžko říct, možné jsou asi všechny. Možnost č. 1 by byl průšvih, znamenalo by to, že se stávající implementaci Btrfs nedá moc věřit (používám přitom skoro úplně nejnovější jádro, protože na použitém stroji běží rolling updates distribuce openSUSE Tumbleweed; což na druhou stranu může také znamenat nové a dosud neodhalené chyby v implementaci Btrfs). Možnost č. 3 by byla asi nejpříznivější případ, protože vypnutí UAS komunikace by mělo podobným problémů zabránit.

Trošku se ale bojím, že správně může být možnost č. 4. SMR dost možná není dobrý nápad a Seagate disky statisticky vzato nemají dobrou pověst. Děsivé ale je, že když to bude používat BFU na Windows s NTFS, tak mu na disku budou tiše degradovat data a on se o tom nedozví, dokud mu ten jeho veledůležitý .docx soubor MS Word odmítne otevřít. A velmi obdobně dopadne i zkušený linuxák, pokud použije Ext4 nebo jiný běžný filesystém, který integritu dat čtených z disku nehlídá a spoléhá se jen na to, zda disk samotný neohlásí, že se mu data nepodařilo přečíst. A z toho co vidím ve výpisu messages bufferu jádra se zdá, že disk žádné problémy nehlásí. Také S.M.A.R.T. je čistý. :-/

Buď jak buď, pokud pomineme variantu č. 1, tj. chybu v samotné implementaci Btrfs, tak před všemi ostatními možnostmi Btrfs efektivně ochrání a může vám zachránit data (pokud použijete nějakou formu redundance) nebo vás alespoň upozornit, že je něco velmi špatně. Zvažte použití Btrfs!

Zálohujte, zálohuje, zálohujte a buďte při tom paranoidní!

Co k tomu napsat víc? Zálohujte, zálohujte, zálohujte a buďte přitom paranoidní! Mějte nejen několik kopií a minimálně jednu fyzicky odpojenou od počítače i elektrické sítě, ale používejte i různé technologie. Pokud běžně používáte Windows a data máte na NTFS, zálohujte z Linuxu na Ext4 a/nebo Btrfs (pokud používáte Btrfs, nezapomeňte na jeho údržbu). Pokud běžně používáte Linux, možná se nemusíte stydět zálohovat v jedné kopii na NTFS. Ona se totiž občas objeví chyba v implementaci konkrétního souborového systému v konkrétním operačním systému, která vám sežere data. Pokud není dat mnoho, nebuďte líní je jednou za čas zapsat na nějaké optické médium. A nemusí být od věci, pokud to bude médium, které fyzicky neumí přepis jednou zapsaných dat. Pokud máte přístup k nějakým páskám nebo jiné „enterprise“ úložné technologii, mějte alespoň jednu kopii tam. Mějte různé kopie geograficky oddělené – zavezte jednu kopii k babičce na druhý konec republiky, mějte jednu kopii v šuplíku v práci na druhém konci města. Oceníte to, pokud vám byt vyplaví povodeň. A samozřejmě mějte uložené i historické verze dat – rdiff-backup, Btrfs snapshoty a další jsou vaši dobří kamarádi.

       

Anketa

Anketa

Obrázky

Komentáře

[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