Dotaz: BTRFS recovery

[Reclip]

Zdravim,

potreboval bych, prosim, poradit, jak na zachranu dat z BTRFS. Mam server, co bezi na synology, v nem 2x3TB disk v RAID 1. Ted mi ovsem server nenabehnul, takze zrejme nejaka chyba na obou discich naraz, nevim. Zvlastni je i to, ze pokud jsou disky pripojene na MB, router vubec neprideli serveru IP. Po odebrani disku, pripadne pripojeni jineho disku vse funguje normalne.

Problem nastava se zachranou dat z disku. Jde mi samozrejme hlavne o foto, zbytek vem cert.

Zkousel jsem ruzne navody na netu, ale disk se mi vubec nepodarilo namountovat a pri vypisu fdisku mi to ukaze jenom oddil o velikosti cca 750GB. Disk /dev/sdb: 746.53 GiB, 801569726464 bytes, 1565565872 sectors Disk model: 30EFRX External Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000

Takze nevim, zda je nejaka chyba v GPT a jestli to jde bud nejak opravit nebo alespon zachranit data.

Bohuzel nejsem zdatny linuxak, tak uvitam pomoc pro debila :)

Kazdopadne jsem zjistil, ze programy na zachranu dat pracuji primarne pro ext4, takze BTRFS uz asi ne-e.

Predem dik

---

---

Odpovědi

[Jendа]

Ten výpis neukazuje žádné oddíly.

file -Ls /dev/sdb, hd /dev/sdb|less a jen tak zhruba prosvištět začátek, pak najít magic number btrfs případně zjistit jestli testdisk má btrfs podporu a použít ho (testdisk hledá na disku filesystémy podle magic numbers/známých datových struktur).

[Zoufalec]

Nepoužívat Synology.

[Golis]

mnohokrat som tu na tomto fore cital ze BTRFS je FS 21ho storocia, ze EXT4 a XFS, no len pani inzinieri z 21ho storocia zabudli na spolahlivost a na nastroje ktore dokazu aspon s casti obnovit data.

dal sim si na prcovny laptop pod vlyvom diskussi BTRFS, hned cez vikend idem spat na EXT4.

[Andrej]

Tohle je stejně dementní komentář jako: Jezdil jsem Trabantem a všechno bylo v pohodě. Teď jsem si koupil Rolls-Royce, ale naboural mě kamión. To je hrůza! Hned se vracím k Trabantu!

Jak přesně by Ext4 ustál selhání dvou disků v RAID1? Pomocí kouzel a magie? Jak mu ty zázračné nástroje v takovém případě pomůžou? Asi nijak, nemluvě o tom, že Ext4 dokonce ani neumí žádný vestavěný RAID1. Totéž platí pro XFS.

Jasně, vrátit se k zastaralému filesystému bez CoW, checksumů, snapshotů i RAIDu je opravdu skvělý nápad. Logika par excellence.

Já jsem si takhle dal na pracovní (a všechny osobní) počítače Btrfs v roce 2010 a zatím naprostá spokojenost. Že je někdo o dekádu pozadu a ještě se tím chlubí, to mi hlava nebere. Dokonce už i Fedora chápe, jak se věci mají. Ale vždycky se najde pár FUDistů, kteří by nejraději používali FAT12 nebo co.

…zabudli na spolahlivost…

Hloupý pokus o vtip? Jinak si to neumím vysvětlit. Ext4 nebo XFS nesahají Btrfs ani po kotníky, pokud jde o spolehlivost. Takže, kde je norma spolehlivosti? S čím tady srovnáváme? Podle jakých měřítek? S jakými features? S jakými požadavky? Aby to ustálo selhání všech disků?

…a na nastroje ktore dokazu aspon s casti obnovit data…

Tohle myslíš fakt vážně? Nebo na svém počítači nemáš nainstalovaný příkaz man? Nebo jen tak šíříš FUD?

• man btrfs-check: diagnostika s možností oprav lehce poškozeného filesystému
• man btrfs-rescue: veliké kladivo; souprava nástrojů k obnovení (alespoň částečnému) těžce poškozeného filesystému, pořád ještě s nadějí, že by se dal namountovat
• man btrfs-restore: sada low-level nástrojů k získání čitelných dat (a pokud možno souborů) z filesystému, který je beznadějně poškozený a s mountem už se nepočítá; někdy se doporučuje jako první zálohovací mechanismus před experimenty s výše uvedenými nástroji

Stojí za zdůraznění, že tam^^^ jsou (samozřejmě) taky nástroje schopné proskenovat celý disk a hledat (kdekoliv) Btrfs metadata. Takže dokonce i když úplně odejde tabulka GPT a není jasné, kde byl který oddíl, nemusí být situace beznadějná.

[Zoufalec]

Related: dm-crypt + dm-integrity + dm-raid = awesome!

[Andrej]

Což je ovšem obrovský voser, ve srovnání s vytvořením Btrfs. Jsou to jsou tři oddělené vrstvy, které je třeba odděleně vytvořit a nakonfigurovat.

Tohle je skvělé srovnání. Autor sice nakonec opustil Btrfs a zůstal jenom u ZFS, protože potřeboval kompatibilitu s FreeBSD, nicméně na pointě to nic nemění: Redundance a RAID má být součástí filesystému, nikoliv další vrstva abstrakce, která o filesystému neví.

[Peter Golis]

Že to tomu trolovi žereš.

[Andrej]

O nějakého trolla vůbec nejde! Ten je mi u prdele.

Jde o ostatní čtenáře, kteří případně tohle vlákno najdou v budoucnu.

Především kvůli nim je potřeba oponovat nesmyslům. (Což se netýká jenom informatiky nebo IT; nesmysly, pověry a pavědy existují v jiných oborech taky.)

[Heron]

Mě tohle nějak přestalo bavit. Ano, snaha je to důležitá, ale otázkou je, jaké to má reálné výsledky. Vem si už jen titulek tohoto dotazu. BTRFS recovery. Naprosto typický titulek u většiny problémů, kde se BTRFS jen mihne. Univerzální viník. A potom někdo argumentuje tím, že BTRFS je na hovno, protože se stačí podívat na výsledky v Google. Málokdo si dá práci strukturovat ten problém a vidím to i u svých kámošů. Jednomu před rokem selhal HW, MD raid udělal chybný zápis - obnovil sektory z vadného disku na ty zdravé, měl to v raid5, takže korupce celkem velká - btrfs to prostě nerozdýchal. A ten kámoš o té události dodnes mluví jako o havárii btrfs, přičemž reálně zhavaroval HW a následně se s tím nevyrovnal MD, který tu situaci ještě zhoršil.

[Andrej]

Jednomu před rokem selhal HW, MD raid udělal chybný zápis - obnovil sektory z vadného disku na ty zdravé, měl to v raid5, takže korupce celkem velká - btrfs to prostě nerozdýchal. A ten kámoš o té události dodnes mluví jako o havárii btrfs, přičemž reálně zhavaroval HW a následně se s tím nevyrovnal MD, který tu situaci ještě zhoršil.

Ovšem přesně tomuhle je důležité v debatách oponovat, když se takový nesmysl objeví. Především proto, že kdyby tam nebyl mdadm (pseudo-RAID, ve skutečnosti AID, který by neměl existovat, měl by být označený za nebezpečný + deprecated atd.), nýbrž pouze Btrfs se svým vestavěným RAIDem, normálně by to ten systém ustál bez ztráty dat.

Takhle už několika lidem odešel mdadm RAID6 kvůli problému s jedním diskem. (A člověk by čekal, že k tomu je potřeba problém se třemi disky.) Ano, byla to lidská chyba, konkrétně přepsání jednoho disku asi z poloviny nulami (a světe div se, v té první polovině byla všechna podstatná data z využitých stripů toho pole). (Klasika: Debugging problémů s diskem na běžícím systému, omyl v označení disků, hoplá!) Problém byl, že metadata byla ve staré verzi mdadm 0.9 na konci disku. Takže metadata tam zůstala. Pak se spustil resilvering. (!!!) No a jak dopadl, to je asi jasné: Všechna data byla pryč.

Tohle^^^ by Btrfs RAID6 normálně ustál. Což je potřeba připomínat všem šiřitelům FUDů:

• Ne, Btrfs nemůže za váš rozbitý hardware.
• Ne, Btrfs nemůže za (ostatní) rozbitý software (mdadm), který s ním chybně zkombinujete.
• Ne, Btrfs nemůže za všechna vaše špatná rozhodnutí ohledně RAIDu nebo zálohování.

[Numu]

Jéé povídej o tom jak Btrfs RAID5 a 6 je stabilní, kvalitní a bez problémový.

[Andrej]

…stabilní, kvalitní a bez problémový.

Ve srovnání s čím??? (Povídej, jak zbytečně šíříš FUD.)

Nicméně i tak „celkově“ opravdu je stabilní, kvalitní a spolehlivý. (Sám RAID5 a RAID6 na Btrfs používám víc než 5 let, k naprosté spokojenosti.)

Kromě toho, s formáty raid1c3 a raid1c4 pro metadata už zmizely i zbytky (hypotetického) write hole problému na Btrfs.

Tvl. Tihle anonymové na ABCLinuxu jsou fakt problém.

[marbu]

Kromě toho, s formáty raid1c3 a raid1c4 pro metadata už zmizely i zbytky (hypotetického) write hole problému na Btrfs.

Na Btrfs Status wikistránce (aktualizováné vzhledem k aktuálnímu kernelu řady 5.7), se pořád píše:

RAID56 write hole still exists (see below)

Some fixes went to 4.12, namely scrub and auto-repair fixes. Feature marked as mostly OK for now.

Further fixes to raid56 related code are applied each release. The write hole is the last missing part, preliminary patches have been posted but needed to be reworked. The parity not checksummed note has been removed.

Čímž nechci zpochybňovat opravy v RAID56 kódu z poslední doby. Nicméně tvrdit, že tento problém je už zcela vyřešen, je ještě poněkud předčasné.

Zda je třeba se toho v produkci bát nemůžu říct, to si musí každý zodpovědět sám, ale minimálně je dobré tomuto věnovat zvýšenou pozornost při testování před nasazením.

[Andrej]

Na Btrfs Status wikistránce (aktualizováné vzhledem k aktuálnímu kernelu řady 5.7), se pořád píše:

RAID56 write hole still exists (see below)

S čím srovnáváme? Tohle je zase ten starý známý dvojí metr:

• mdadm má write hole. Mnohem horší než Btrfs.
• dmraid má write hole. Mnohem horší než Btrfs.
• Většina AIDů (chybně označovaných jako RAID), softwarových i hardwarových, má write hole. Mnohem horší než Btrfs.

Proč je tedy jeden (teoretický) problém (který už má dnes řešení) na Btrfs tak strašně důležitý, zatímco jinde ne?

Údajně může vzniknout write hole, pokud má člověk raid5/6 na datech i metadatech a pokud dojde k patologické situaci, kdy po selhání N - 1 disků (kde N je míra redundance) dojde k nečekanému vypnutí počítače a během následné obnovy selže specifickým způsobem další, N-tý disk. Dobře. Nicméně jedná se o

1. řešitelný problém (který například ZFS vyřešil),
2. dočasný problém (jen kdyby autoři patchsetů z roku 2017 (a pozdějších) měli víc času a motivace, čemuž by pomohlo méně FUDu kolem Btrfs) a konečně taky
3. problém se snadným workaroundem: raid5 data + raid1c3 metadata nebo raid6 data + raid1c4 metadata.

Duplikace těch metadat sice kousek prostoru stojí, ale pokud někdo trpí tak strašnou nejistotou kolem hypotetické write hole na Btrfs (zatímco zcela reálné riziko na mdadm nebo dmraid, navíc v kombinaci s filesystémy bez checksumů, srdnatě toleruje), může zvolit tuhle možnost. Já mám raid5/6 data i metadata a rebalance metadat na raid1c3/4 zatím neplánuju.

Zda je třeba se toho v produkci bát nemůžu říct, to si musí každý zodpovědět sám, ale minimálně je dobré tomuto věnovat zvýšenou pozornost při testování před nasazením.

Největší pozornost před nasazením je třeba věnovat (eliminaci) Ext4, který nemá checksumy dat a který měl v posledních 10 letech pravidelně každé 3 roky pořádný výbuch spojený se ztrátou dat. (Leč Ext4 si to může dovolit, protože je prý "stabilní". Dvojí metr.)

Zda je třeba bát se Ext4 a obecně všech FS bez kompletních checksumů, které se považují za "stabilní" (ač jejich definice "stability" neodpovídá dnešnímu hardwaru a dnešní realitě), to se dá říct celkem s jistotou: Ano.

[marbu]

S čím srovnáváme? Tohle je zase ten starý známý dvojí metr ... Proč je tedy jeden (teoretický) problém (který už má dnes řešení) na Btrfs tak strašně důležitý, zatímco jinde ne?

Srovnávám se stavem samotného btrfs z roku 2016, jak jej prezentují jeho vývojáři, kdy se problém s módem "RAID56" v brtrfs řešil:

Scrub + RAID56: Unstable, will verify but not repair 
RAID56: Unstable, write hole still exists, parity not checksummed 

Stejně tak si vybavuju, že se do kernelu postupně dostalo několik oprav, viz. např. tebou zmiňované změny z roku 2017.

Takže když tu teď v diskusi vidím, jak se lidi dohadují, zda je to pořešené nebo ne, otevřu si znovu status wiki stránku btrfs a vidím:

Scrub + RAID56: mostly OK, mostly OK 
RAID56: Unstable, write hole still exists (see below)

Což je sice pokrok, ale takto napsané to nevyznívá tak, že už je z praktického hlediska pořešené. Definice těch stavů totiž říkají:

mostly OK: safe for general use, there are some known problems that do not affect majority of users
Unstable: do not use for other then testing purposes, known severe problems, missing implementation of some core parts 

Takže pokud je skutečné stav RAID56 módu v brtfs takový, jak píšeš, představoval bych si, že by v té tabulce měli aspoň "mostly OK" místo "unstable".

Ale je fakt, že popis RAID56 módu vyznívá o něco líp (v podstatě tam navrhují stejný workaround jako ty):

The parity RAID code has a specific issue with regard to data integrity: see "write hole", below. It should not be used for metadata. For data, it should be safe as long as a scrub is run immediately after any unclean shutdown.

Každopádně díky za odpověď. Nic proti btrfs nemám, sám btrfs na několika místech mám (ale ne v raid56 módu). Ale v tomto případě nejde ani tak o fud jako o nešťastnou komunikaci ze strany btrfs vývojářů. Podobně jako když se filesystém formát označil za stabilní.

[Andrej]

Scrub + RAID56: mostly OK, mostly OK 
RAID56: Unstable, write hole still exists (see below)

Což je sice pokrok, ale takto napsané to nevyznívá tak, že už je z praktického hlediska pořešené.

A u mdadm a dmraid tedy nevadí, že tohle není, nebylo a nikdy nebude "pořešené"? Já ten dvojí metr prostě nechápu.

Write hole na Btrfs je zajímavý teoretický koncept, který sice nikdy nikdo neviděl v praxi, ale mohl by (čistě teoreticky) nastat, když se ve formální verifikaci celého přístupu prohledají všechny okrajové případy.

Nicméně uživatelé nebezpečného šílenství typu dmraid nebo mdadm už léta (desetiletí!) všechna rizika s tím spojená ochotně přijímají. Tak proč je najednou jakési zanedbatelné, dočasné a teoretické riziko na Btrfs problém, který stojí za řeč?

Definice těch stavů totiž říkají:

mostly OK: safe for general use, there are some known problems that do not affect majority of users
Unstable: do not use for other then testing purposes, known severe problems, missing implementation of some core parts 

Takže pokud je skutečné stav RAID56 módu v brtfs takový, jak píšeš, představoval bych si, že by v té tabulce měli aspoň "mostly OK" místo "unstable".

Mé oblíbené odkazy z nedávné historie Ext4 ([2009] [2012] [2015] [2018]) zase říkají, že Ext4 je průser jak mraky, který není ani mostly OK, natož stable nebo co, a nikdo už to nikdy nevyřeší a neopraví. Přesto je rizikový Ext4 s rizikovým AIDem (mdadm / dmraid) dál "podporovaný" některými instalátory a dokonce (bohužel) i doporučovaný.

Kromě toho, co je to vlastně raid5/6 mód? Mód pro metadata a mód pro data jsou dvě oddělené věci. Proto jsem zmiňoval raid1c3/4: Kdo si opravdu myslí, že Btfs musí být nejen nesrovnatelně lepší než mdadm/dmraid (což už spoustu let je), ale dokonce přímo dokonalý (a otázka je, proč si tohle pořád někdo myslí), ten si může u metadat nastavit takový režim, který write hole vylučuje, tedy replikovaný raid1c3/4. Pseudo-problém vyřešen.

Případně pokud má někdo dojem, že ZFS (se svým úžasným kódem v C89, který se s každou druhou verzí Linuxu nepřeloží a musí se počkat, až někdo patche zas opraví — ano, já vím, může za to CDDL, ale co se dá dělat, tak to prostě je) je lepší volba, nechť klidně používá ZFS. A kdoví, třeba ZFS nakonec je dobrá volba. Linux si nasral do vlastního hnízda napřed odmítnutím Reiser4, dost možná nejlepšího filesystému všech dob, potom zdržováním restrukturalizace VFS tolik potřebné pro Btrfs / ZFS a ve finále ještě otrávením celého "ekosystému" kolosální kravinou typu Tux3 (kde je tomu nesmyslu dnes konec?!), což Btrfs soustavně házelo klacky pod nohy. Solaris se ve stejném období vyvíjel solidním tempem. (Škoda, že Solaris dopadl, jak dopadl.)

Každopádně díky za odpověď. Nic proti btrfs nemám, sám btrfs na několika místech mám (ale ne v raid56 módu).

Data nebo metadata? To je, oč tu běží.

Můj raid5 a raid6 z let 2015 a 2017 se zatím těší plnému zdraví. Data i metadata mám ve stejném formátu, protože v těch dávných dobách ještě nebyl raid1c3/4. Jediné, na čem mi záleží, je fakt, že to řešení je nejspolehlivější, jaké můžu mít — lepší než softwarový AID (dmraid, mdadm), napůl-hardwarový pseudo-RAID (tedy zase jenom AID) atd.

Ale v tomto případě nejde ani tak o fud jako o nešťastnou komunikaci ze strany btrfs vývojářů.

Ta komunikace je sice nešťastná, ale přijde mi, že celkem odpovídá přístupu nedůvtipného okolí k celému projektu a k práci těch vývojářů.

Fedora 33 bude mít Btrfs (konečně, s 10-letým zpožděním!) jako implicitní filesystém v instalátoru. Dobře, to je bezva.

Jenže Solaris měl už v roce 2009 takovou samozřejmost, že update se instaloval do naklonovaného atomického snapshotu filesystému. Pak se jednoduše snapshot s novým systémem povýšil na ten "hlavní", kopie se degradovala na klon a nabootovalo se z nového atomického obrazu. Nikdy se nebootovalo z něčeho, co by mohlo mít nekonzistentně přepsanou část programů nebo (kni)hoven. Kdo dnes takhle využívá Btrfs? Kromě několika menšinových distribucí tohle zatím nikde není. I Fedora volí přehnaně konzervativní nastavení, kde Btrfs snapshoty vůbec nebudou hlavním tématem (kromě systemd-homed) a kde se bude systém při aktualizacích postaru přepisovat.

To^^^ se sice zdá být hloupé a smutné, jenže když se člověk podívá an mailing list Fedory z doby půl roku zpátky, jak tam pár idiotů navrhovalo odstranění Btrfs z distribučního kernelu Fedory (opravdu! bez prdele!), najednou se prostý fakt, že se konečně Btrfs stává implicitním filesystémem, jeví jako úspěch.

Stylu komunikace vývojářů Btrfs se tedy vůbec nedivím! Kdyby mi někdo házel klacky pod nohy plus zároveň chrchlal zelenáče do ksichtu, taky by se mi nechtělo komunikovat.

Podobně jako když se filesystém formát označil za stabilní.

Co to znamená stabilní? Poslední podstatná změna diskového formátu Btrfs se datuje někdy do dob kernelu 2.6.31 ze srpna 2009.

Podobně jako ZFS má svoji feature bitmap (man zpool-features), která postupně nahradila těžko udržitelné jednorozměrné verze poolů, má i Btrfs své incompatibility flags (viditelné třeba v btrfs inspect-internal dump-super <zařízení>), které jednoduše brání použití Btrfs s novými rozšířeními na fosilním kernelu, který ta rozšíření nepodporuje. Jak by to mělo být jinak? To by měl být filesystém zmrazený a 20 let stagnoval? To snad ne; to už tu v minulosti bylo a nebylo to dobré.

[LarryL]

update se instaloval do naklonovaného atomického snapshotu filesystému. Pak se jednoduše snapshot s novým systémem povýšil na ten "hlavní", kopie se degradovala na klon a nabootovalo se z nového atomického obrazu. Nikdy se nebootovalo z něčeho, co by mohlo mít nekonzistentně přepsanou část programů nebo (kni)hoven. Kdo dnes takhle využívá Btrfs? Kromě několika menšinových distribucí tohle zatím nikde není.

Něco takového by se mi líbilo. Můžeš prosím uvést, které menšinové distribuce tohle využívají?

Případně jestli existují nějaké aplikace (scripty), které by takové chování mohly docílit i na [*]buntu nebo Fedoře?

[Andrej]

Všechno, co zmiňuješ, existuje, ale já sám nic z toho (denně) nepoužívám, kromě pár pokusů ve VM, takže to nemůžu doporučit / zavrhnout. Něco z toho taky nejsou distribuce, ale spíš obecné (kni)hovny / koncepty použitelné v různých distribucích.

• Kali má nějaké automatické snapshoty před aktualizacemi. To vypadá zajímavě, ale přece jenom už mi není 20 a nekalím každý den, tak nevím.
• Pro Ubuntu byl apt-btrfs-snapshot. Asi to ještě existuje, ale Ubuntu nemám / nechci, tak nevím. (Datum vzniku toho balíčku ukazuje, jak zoufale je celé nasazení Btrfs opožděné.)
• Nejobecněji obecné řešení je asi libostree. Kdysi jsem to zkoušel, ale trochu mě odradil nedostatek podpory v Archu; sice to fungovalo, ale bylo tam až moc manuálních kroků, které bylo potřeba provést v souvislosti s aktualizacemi. Umím si představit nasazení tohoto na skupinu experimentálních LXC kontejnerů nebo něco takového. Na hlavním systému mi to nechybí, přiznám se.
• Pro Fedoru něco takového kdysi mělo být, strašně dávno, skoro před desetiletím, a že to souviselo s Oraclem, to mě překvapuje dodnes. (Že Oracle podporoval Btrfs předtím, než koupil ZFS, to mě nepřekvapuje. Co se dělo poté, to už jsem raději nesledoval a co ke mně dolehlo, tomu jsem se nestačil divit.)
• Fedora dnes: Snad už konečně! Každopádně, aktuální Fedoru teď zrovna při ruce nemám, takže to nemám vyzkoušené.
• Snapper od OpenSUSE je známý. Dokonce i v Archu. Prý je v Archu lépe podporovaný než ostree. Ale ostree mě kdysi popudilo a Snapper jsem nikdy nevyzkoušel, tak nevím.
• Nakonec jediné, co fakt sám osobně používám, je systemd-homed. To funguje. Samozřejmě to nejsou ani náhodou celosystémové snapshoty. Má to své velmi omezené pole působnosti a snaží se to (což je dobře!) být nezávislé na distribuci a na (případných) distribučních celosystémových snapshotech.

[k3dAR]

[...]Pro Ubuntu byl apt-btrfs-snapshot. Asi to ještě existuje, ale Ubuntu nemám / nechci, tak nevím[...]

je to i v 20.04 (Xubuntu mam, ale zatim bez BTRFS, takze chovani z praxe "balicku" neznam)

[LarryL]

Dík moc za info.

[Heron]

Linux si nasral do vlastního hnízda napřed odmítnutím Reiser4, dost možná nejlepšího filesystému všech dob

V čem? To není provokativní otázka, fakt mě to zajímá. O reiser jsem se nikdy nezajímal do hloubky, jen se občas objeví zpráva, že reiser přináší nový "geniální" koncept a když si to přečtu, tak to není ani nové, ani nijak zvlášť geniální, ale hlavně, to prakticky nikdy nemá nějaký dopad. Naposledy třeba O(1) alokátor. Jako samostatně super, ale dopad nulový a zabitý jinými věcmi.

A když jsem si přečetl o raiser "multidevice", tak jsem se nestačil divit. V praxi si to nedovedu představit administrovat. Pro mě jako admina je jediný správný multidevice přístup ten, který má btrfs. Prostě přidat disk, tečka. Jedna operace.

Ale možná to má nějakou kvalitu, kterou jsem buď nenašel nebo nepochopil. Proto se ptám zcela vážně.

Kdo dnes takhle využívá Btrfs?

Ve skutečnosti skoro nikdo nepoužívá ani snapshoty jako zcela běžnou součástí práce. Pokud už mají btrfs, tak snapy používají většinou jen pro konzistentní zálohy nebo to nechávají na OS. Já si život bez snapshotů už vůbec nedovedu představit a toto byla pro mě killer feature btrfs od počátku a věděl jsem přesně k čemu je chci. Zjednodušeně se to dá popsat jako systém pro správu verzí velkých dat. Něco jako git, ale pro subvolume v GB nebo TB. Před každou operací s daty si udělám snapshot a potom můžu svobodně pracovat. Takhle mám strom snapshotů podobně jako větvě v gitu. Ale ještě jsem nenarazil na nikoho, kdo by to takto používal. (Jasně, že existují, ale je jich teda mnohem méně, než bych čekal.)

Další věcí, kterou bych od storage moc a moc chtěl, je volitelná redundace per subvolume. U ZFS se redundance řeší na úrovni vdevů a ty tvoří jeden zpool. U btrfs se redundace tvoří napříč celým FS a může být jen jedna. Nevím o žádném storage systému, který by disky bral jen jako "zásobárnu bloků" a potom je možnost si zvolit redundanci per subvolume. (Ve skutečnosti ano, toto lze mít v LVM, kdy si nad VG vytvořím klidně LV mirror, další LV linear, apod. Ale tím veškeré výhody končí.) Takže bych si přál úpravu btrfs takovou, že si až u jednotlivých subvolume zvolím redundanci. Jasně, řečeno takto jednoduše to má spoustu nevyřešených případů, jaký typ redundance budou mít snapshoty apod a celkově by se z tohoto přístupu alokátor bloků zbláznil (nejspíš by to bylo hodně pomalé) ale jako koncept jsem toto nikde nenašel. Přitom mě to přijde přirozenější, než redundanci řešit někde dole jak to má třeba ZFS.

[Zoufalec]

[...]

Další věcí, kterou bych od storage moc a moc chtěl, je volitelná redundace per subvolume. [...] Takže bych si přál úpravu btrfs takovou, že si až u jednotlivých subvolume zvolím redundanci.

Features Currently in Development or Planned for Future Implementation:

• [...]
• Object-level mirroring and striping
• [...]

[ewew]

Což je sice pokrok, ale takto napsané to nevyznívá tak, že už je z praktického hlediska pořešené.

Pokial tento fs nebude riadne vyskúšaný, tak do normálnych systémov ich nenasadia. Je dosť problém ak nemáš znalého správcu fs.

A u mdadm a dmraid tedy nevadí, že tohle není, nebylo a nikdy nebude "pořešené"? Já ten dvojí metr prostě nechápu.

Write hole na Btrfs je zajímavý teoretický koncept, který sice nikdy nikdo neviděl v praxi, ale mohl by (čistě teoreticky) nastat, když se ve formální verifikaci celého přístupu prohledají všechny okrajové případy.

Nicméně uživatelé nebezpečného šílenství typu dmraid nebo mdadm už léta (desetiletí!) všechna rizika s tím spojená ochotně přijímají. Tak proč je najednou jakési zanedbatelné, dočasné a teoretické riziko na Btrfs problém, který stojí za řeč?

Tento typ RAID je pole redudantných diskov. Podľa tohto ide o pole kde sú disky podľa typu použivané.

Takže pokud je skutečné stav RAID56 módu v brtfs takový, jak píšeš, představoval bych si, že by v té tabulce měli aspoň "mostly OK" místo "unstable".

Vyskúšali to na hw, ktorý je bežne dostupný alebo len na drahších zostavach ?

Mé oblíbené odkazy z nedávné historie Ext4 ([2009] [2012] [2015] [2018]) zase říkají, že Ext4 je průser jak mraky, který není ani mostly OK, natož stable nebo co, a nikdo už to nikdy nevyřeší a neopraví. Přesto je rizikový Ext4 s rizikovým AIDem (mdadm / dmraid) dál "podporovaný" některými instalátory a dokonce (bohužel) i doporučovaný.

Len pozor aby tu nezačali pribúdať oblúbené odkazy z histórie dynamického BTRFS. K možnosti BTRFS dať upozornie, že na daný fs je nutné mať špecialistu na BTRFS. Jednoducho ak sa ti rozsype normálny fs, ta tie data z tadial dostaneš. Pretože je to predvídateľný systém, ktorý nerozhádže data po disku podľa aktuálného počasia.

Kromě toho, co je to vlastně raid5/6 mód? Mód pro metadata a mód pro data jsou dvě oddělené věci. Proto jsem zmiňoval raid1c3/4: Kdo si opravdu myslí, že Btfs musí být nejen nesrovnatelně lepší než mdadm/dmraid (což už spoustu let je), ale dokonce přímo dokonalý (a otázka je, proč si tohle pořád někdo myslí), ten si může u metadat nastavit takový režim, který write hole vylučuje, tedy replikovaný raid1c3/4. Pseudo-problém vyřešen.

raid5/raid6 je podľa definície pole s distribuovanou paritou a pole s dvojitou paritou.

Data nebo metadata? To je, oč tu běží.

ext4 má od 2012 podporu kontrolných súčtov metadát.

Můj raid5 a raid6 z let 2015 a 2017 se zatím těší plnému zdraví. Data i metadata mám ve stejném formátu, protože v těch dávných dobách ještě nebyl raid1c3/4. Jediné, na čem mi záleží, je fakt, že to řešení je nejspolehlivější, jaké můžu mít — lepší než softwarový AID (dmraid, mdadm), napůl-hardwarový pseudo-RAID (tedy zase jenom AID) atd.

prečo nemáš raid z roku 2020 ?

Co to znamená stabilní? Poslední podstatná změna diskového formátu Btrfs se datuje někdy do dob kernelu 2.6.31 ze srpna 2009.

Stabilný znamená veľmi málo meniaci a samozrejme dobre otestovaná funkcia.

[Andrej]

Pokial tento fs nebude riadne vyskúšaný, tak do normálnych systémov ich nenasadia.

Jasně, on „jenom“ roky běží „jenom“ ve Facebooku a v dalších velkých internetových firmách, „jenom“ na exabytech dat. Takže není vyzkoušený, že? Jaký materiál bereš?

Jednoducho ak sa ti rozsype normálny fs, ta tie data z tadial dostaneš. Pretože je to predvídateľný systém, ktorý nerozhádže data po disku podľa aktuálného počasia.

Kravina. FUD. Odpověď z roku 2010. Nebo neznalost problematiky?

Zaprvé: Btrfs je normální FS. Zastaralé nespolehlivé předpotopní nesmysly na dnešním HW a dnešních velikostech dat nikdo se všemi pěti pohromadě nechce.

Zadruhé: Výše uvádím odkazy na spoustu recovery nástrojů. Když selže pár disků nebo když člověk udělá chybu, s Btrfs je šance na záchranu dat nesrovnatelně vyšší než se zastaralým odpadem typu Ext4. Jen to některým ne a ne docvaknout, tahle základní fakta. No, co už.

raid5/raid6 je podľa definície pole s distribuovanou paritou a pole s dvojitou paritou.

Ale prdlajs. Používáš v roce 2020 asi tak 25+ let starou definici. Redundance se týká dat / částí dat, nikoliv celého pole najednou.

Když chci data na raid5 a metadata na raid6, klidně to tak můžu mít. Kdyż chci replikovaná metadata raid1c4 s daty na raid6, taky žádný problém.

Proto je (mimo jiné) tak prospěšné používat normální dnešní filesystém (Btrfs, ZFS), nikoliv zastaralé AID odpady.

prečo nemáš raid z roku 2020 ?

Zkus hádat!

Protože Btrfs celé ty roky 100% spolehlivě fungoval, včetně výměny disků, a nikdy jsem ho nepotřeboval přeformátovat, za celé ty roky?

Ha! Bingo! To bude ono. Ještě nějaké zbytečné dotazy?

[bigBRAMBOR]

bohužel při všech kvalitach BTRFS má jednu strašnou chybu a nedari se ji zatim odstranit, tou chybou je Andrej, který bohuzel tomuto FS dela medvedi sluzbu a kopirovanim porad stejnych argumentu vice lidi zastraší nez presvedcí, jeho zpusob evangelizace je velmi agresivní, mají vyvolat pocit ze pred BTRFS(ZFS) byly ztráty souborů na denním přádku. BTRFS ano, Andrej ne.

[Andrej]

Ty máš nejspíš problém s chápáním psaného textu. Jinak si tenhle komentář neumím vysvětlit.

Tak především je mi zcela u prdele, jestli dělám Btfs nějakou službu, dobrou nebo medvědí. Jediné, na čem mi záleží, je, zda Btrfs dělá dobrou službu mně. Ano, dělá.

Trollové na ABCLinuxu mají jednu společnou vlastnost: Podsouvají někomu nesmysly, které nikdy neřekl, a tvrdí, že je řekl. Kde přesně jsem tvrdil, že v té či oné době byly ztráty souborů na denním pořádku? Za jakých podmínek? Jak se to projevovalo? Na jakých datech? Na jakých souborech? V jakém kontextu? Prosím přesnou citaci.

Inu, citace nebude, že ano! Nic takového jsem totiž netvrdil. Tak mi laskavě nepodsouvej něco, co jsem netvrdil a co sis náhodně vymyslel.

Asi to budu muset (pokolikáté už?!) vysvětlit polopatě, jako v první třídě. Dobrá, zkusím to. Tady je vysvětlení, speciálně formulované (také) pro dyslektiky:

• V dobách disků o velikostech řádově jednotek GB rozhodně nebylo mizení dat na denním pořádku. Solidní disky na SCSI měly vestavěné checksumy, podporovaly DPO a FUA atd. Doba byla zkrátka jiná. Dat bylo méně, měnila se pomaleji. Požadavky na souborové systémy proto nebyly tak velké. Nějaký obyčejný béčkový UFS klidně stačil. Příliš na tom nezáleželo. Stačil alokátor místa, který nevedl ke katastrofické fragmentaci (což třeba UFS měl vyřešeno solidně), a byl klid.
• Dnes máme období disků o velikostech TB, ba dokonce se postupně objevují desítky TB. Jenže zároveň bychom chtěli, aby tam ta data všecha zůstala, každý bit. Tedy abychom nemuseli řešit to, že třeba v každých 100 GB bude jeden bit špatně, jen co uplyne rok. Ale ouha, dnešní disky už dávno nemají kvality těch "luxusních" SCSI disků, nemají DPO a FUA, jediným cílem výrobce je vyhrát nějaký podstatný benchmark, prodat toho aspoň deset milionů kusů a posunout se zase o kousek dál.
• Co je potom konečným důsledkem ohromného nárůstu kapacity disků a zhoršení jejich celkové spolehlivosti? Mnohem silnější požadavky na filesystém, na redundanci a na integritu dat na úrovni filesystému!

Tak. Už? Už chápeš, proč se dřív o silent data corruption tolik nemluvilo? Nebo to mám vysvětlit ještě podrobněji, ještě polopatěji?

[Heron]

ba dokonce se postupně objevují desítky TB

Mě by jenom zajímalo kde se bere na trhu poptávka pro takto velké disky. Protože kromě velikosti to nic nenabízí. Je to vesměs pomalu otáčkové, SMR, s nutností přeskládání. Nevím, jestli laik ocení takto velký disk se všemi svými daty o která během jedné události přijde. Lze namítnout, že laici mají všechno zálohované v cloudu, ale velikosti všech těch různých ms / google drive jsou v jednotkách GB. Takže jednou přijdou o xTB dat z toho jediného disku, který mají.

S narůstající odborností si tento uživatel bude uvědomovat potřebu redundance a zálohování. Tady je velká velikost už jenom překážkou, budou se mu prodlužovat časy. Tzn poptávka po těchto diskách bude s narůstající odborností klesat.

Nevím (nikde jsem to neviděl), zda existuje možnost chovat se k zónového SMR jako k souboru pásek. Tj na každou zónu zapisovat kontinuální data jako na pásku. Tím by se otevírala další možnost využití SMR jako zálohovacího media místo pásek. Tj ze zásadní nevýhody pro blokové FS z toho udělat výhodu. Ale nikde jsem tohle neviděl.

Co z trhu skoro úplně zmizelo byl dřívější standard obyč 7200rpm disků. Nechápu proč. Rychlost to mělo dobrou (přijatelnou), mělo to rozumné velikosti (to prakticky všechno až do příchodu SMR) vzhledem k rychlosti, takže se to dalo dobře použít na redundanci.

Takže nakonec zbývají jen zpomalené CMR. A to jen ve velikosti 3.5".

[Ruža Becelin]

Mě by jenom zajímalo kde se bere na trhu poptávka pro takto velké disky

U nas, co si zalohujeme internet

[k3dAR]

zrovna pred par dny sem kvuli jednomu komentari na root dohledaval co se dnes da koupit za 2.5" NonSMR a nestacil sem se divit, pred 2 lety sem tu resil 2.5" 3 nebo 4TB, nakonec se dopatral jen k 1modelu 3TB od Toshiby, ten se ale ted uz bohuzel nevyrabi, nastesti sem "stihl" koupit 2ks... nicemne dnes v 2.5":

- WD Blue i Black CMR <=500GB, jen Red ma 1TB variantu i CMR (7mm)
- Toshiba ma 1TB variantu i CMR (9mm)
- Seagate nema v 2.5" s CMR ZADNEJ, SMR i v 500GB

tzn. 1TB CMR v 7mm jedine 1 model WD Red 1TB CMR v 9mm jedine 1 model od Seagate 2TB v CMR opravdu zadnej...

[Heron]

Seagate má k tomu alespoň přehlednou tabulku. Ve 2.5 nic.

[Andrej]

Pod pojmem disky se může skrývat spousta věcí.

Samozřejmě, že v datových centrech jsou (řekněme) SSD s kapacitami asi tak o řád+ nad těmi, které se dají koupit v eshopech. Jenom prostě nejsou k mání veřejně, souvisí s nimi dvě spousty obchodních tajemství atd.

Nevím (nikde jsem to neviděl), zda existuje možnost chovat se k zónového SMR jako k souboru pásek.

Spíš pořád existují pásky, jako last resort. Slovo disk už má dnes příliš mnoho přetížených významů.

Co z trhu skoro úplně zmizelo byl dřívější standard obyč 7200rpm disků.

To mě tolik netankuje. Mám doma nějaké 5TB disky Mořskábrána (ST5000LM000), ultra-staré (tj. v roce 2016 už byly ke koupi), jsou to 2,5 neandrtálské jednotky a mají jenom 5400 otáček. Pokud jde o rychlost čtení, klidně nějakých 140 MB/s dají. Nevím, jestli jsem někdy měl disk o velikosti 3,5 neandrtálské jednotky, který by tohle dal. Čím vyšší kapacita, tím vyšší je hustota záznamu. (Ano, dobře, zrovna u těch mých disků to neplatí úplně dokonale, protože jsou strašně tlusté a mají tedy plotny navíc.) Čím vyšší je hustota záznamu, tím vyšší může být rychlost kontinuálního čtení.

[Heron]

Pokud jde o rychlost čtení, klidně nějakých 140 MB/s dají. Nevím, jestli jsem někdy měl disk o velikosti 3,5 neandrtálské jednotky, který by tohle dal.

Kontinuální čtení dá klidně i přes 200MB/s, to není problém. Rotační rychlost ale chceš pro náhodné čtení / zápisy. Nebo pro práci s mnoha soubory. Tam je rozdíl mezi 7200rpm a 5400rpm už docela znát (120 vs 90 iops).

[Andrej]

No nevím. Tak si nastavím tak nehorázně dlouhý vm.dirty_writeback_centisecs, až je mi to trapné, a ono se to zlepší, včetně malých souborů.

S tím souvisí (mimochodem) jedna z věcí, kterou jsi v chybějících features Btrfs nezmínil (*): Heterogenní pole, kde se kombinují disky a SSD, takže všechno je zálohované, kapacita je dostatečně obrovská, ale nejsou tam tyhle nesmyslné bottlenecky dané (bezprostředně) tím, co disk zapíše za sekundu. Bottleneck se posouvá trochu jinam … třeba tam, co disk zapíše za den, ne hned teď za pár sekund.

• Jirka Paroubek: Kdo z vás to má???
• ZFS: No, já bych to měl!!!
• Btrfs: [[strašně se stydí a mlčí]]

(*) Samozřejmě s odděleným nastavením redundance pro každý subvolume bych nadšeně souhlasil, ale je i spousta dalších vymožeností, které tam ještě chybí.

[Heron]

Zrovna na tohle moc nevěřím. Pole se musí vypořádat s požadovanou zátěží kdykoliv a odkládat něco na pak je většinou cesta do pekel. Protože se může stát (a podle Murphyho se to stane v tu nejhorší možnou chvíli), že se všechny tyhle rychlý device naplní přesně ve chvíli, kdy přijde další zvýšení zátěže a potom to celé jde do kytek.

[Andrej]

No nevím. Já mám zrovna tady 4 TB těch rychlých a 40 TB těch pomalých (no, skoro, když budeme brát metrické TB a ne binární TiB). Abych ty rychlé naplnil nějak naráz, zrovna teď a najednou, to mi přijde krajně nepravděpodobné. Asi počítám na svém desktopu příliš konzervativní věci. No a co se pak bude zálohovat celou noc nebo celý víkend, kdy nejsem doma a/nebo ležím ožralý na záchytce, to mě tolik netrápí, to by se stihlo, než se vrátím. A kdyby ne, tak na těch rychlých to furt je, s redundancí lepší než mají ty pomalé.

[Heron]

Aha, tak já myslel, že se bavíme vážně...

zrovna teď a najednou

To není zrovna teď a najednou, to je v průběhu času. V serverovém provozu se ti to časem naplní vždycky, tam nelze nic odkládat. Proto se postupně ustoupilo i od těch servisních hodin v noci, protože na internetu žádná noc není. Prostě všechny "servisní" operace (vacuum u db, repack u fs apod.) musejí probíhat kontinuálně za provozu.

Ale pokud máš dostatečný buffer, abys to tak akorát naplnil před tím, než tě odvezou a potom to má dost času na flush (a ty taky), tak je asi vše v nejlepším pořádku

[Andrej]

Tak dostatečně velký buffer sice mám, ale s implementací nejsem spokojený, protože Btrfs zatím neumí právě ta heterogenní pole. Takže tam mám cosi ošklivého, jako rsync a tak. Filesystémy na discích a na SSD jsou tedy oddělené. Ještě bych mohl mít bcache, ale nějak se toho bojím a přijde mi to v mnoha směrech ošklivé.

[Filip Jirsák]

Nevím (nikde jsem to neviděl), zda existuje možnost chovat se k zónového SMR jako k souboru pásek. Tj na každou zónu zapisovat kontinuální data jako na pásku. Tím by se otevírala další možnost využití SMR jako zálohovacího media místo pásek. Tj ze zásadní nevýhody pro blokové FS z toho udělat výhodu. Ale nikde jsem tohle neviděl.

Jmenuje se to „host managed“ SMR. Např. Ultrastar DC HC600 SMR Series

[Heron]

Jasně. Mě šlo spíš o softwarovou podporu, jestli je přímej přístup k jednotlivým zónám jako k samostatným zařízením. Tj něco jako /dev/disk/id/zones/0-xxx. Nebo jestli se to někde tímto způsobem používá (v OSS OS, ne v proprietárních polích).

[ewew]

Jasně, on „jenom“ roky běží „jenom“ ve Facebooku a v dalších velkých internetových firmách, „jenom“ na exabytech dat. Takže není vyzkoušený, že? Jaký materiál bereš?

Facebook je firma, kde sú data nepodstatné. To že si tam niekto uloži data, ktoré sú nahraditelné.

Kravina. FUD. Odpověď z roku 2010. Nebo neznalost problematiky?

Zaprvé: Btrfs je normální FS. Zastaralé nespolehlivé předpotopní nesmysly na dnešním HW a dnešních velikostech dat nikdo se všemi pěti pohromadě nechce.

Zadruhé: Výše uvádím odkazy na spoustu recovery nástrojů. Když selže pár disků nebo když člověk udělá chybu, s Btrfs je šance na záchranu dat nesrovnatelně vyšší než se zastaralým odpadem typu Ext4. Jen to některým ne a ne docvaknout, tahle základní fakta. No, co už.

Mňa jednoducho tieto dynamické súborové systémy nezaujímaju. Len mi unika pointa neustáleho označovania za odpad.

Prečo už nevyvijaš BTRFS controler ? Asi preto, že tento fs je zaťažení nejakými autorskými právami.

Jednoducho extX systém uloží data ak je to možné súvisle. To znamená jednotlivé bloky sú "jednom rade". Problém dynamických systémov je, že to kopiruje po celom disku, čo značne komplikuje následne obnovenie. Hlavne pri nástrojoch ignorujúcich štruktúru fs. Jednoducho nezáleži na tom aký je fs.

Ale prdlajs. Používáš v roce 2020 asi tak 25+ let starou definici. Redundance se týká dat / částí dat, nikoliv celého pole najednou.

Když chci data na raid5 a metadata na raid6, klidně to tak můžu mít. Kdyż chci replikovaná metadata raid1c4 s daty na raid6, taky žádný problém.

Proto je (mimo jiné) tak prospěšné používat normální dnešní filesystém (Btrfs, ZFS), nikoliv zastaralé AID odpady.

Prečo nebojuješ proti rozdeleniu kernel a user memory space ? Alebo proti rozdeleniu v cpu ring. 0 až 3.

Zkus hádat!

Protože Btrfs celé ty roky 100% spolehlivě fungoval, včetně výměny disků, a nikdy jsem ho nepotřeboval přeformátovat, za celé ty roky?

Ha! Bingo! To bude ono. Ještě nějaké zbytečné dotazy?

Tu ide skôr o aktuálnosť. Nehovoríš, že všetko by malo byť aktuálne ?

[Andrej]

Prečo už nevyvijaš BTRFS controler ? Asi preto, že tento fs je zaťažení nejakými autorskými právami.

A uvědomuješ si aspoň vzdáleně, jaké kraviny tady plácáš? Tohle^^^. To snad ne.

Jednoducho extX systém uloží data ak je to možné súvisle. To znamená jednotlivé bloky sú "jednom rade".

Vždyť to není pravda! Tady mluvíš o FAT, ne o Ext. Prosím, nastuduj si problematiku. Už UFS v 80.-90. letech měl jakési alokační zóny po 48 MB, ve kterých jednotlivému souboru dal maximálně 16 MB souvislých, než přešel na další alokační zónu. Jakkoliv to zní překvapivě, tak to v tehdejších modelech (vzhledem k průměrné velikosti tehdejších souborů) vycházelo jako nejlepší dlouhodobá prevence fragmentace.

Proč by vůbec v UNIXu existovala (obecně, od začátku) struktura inodů, v té či oné podobě přítomná v každém filesystému (včetně Ext4, XFS, Btrfs), kdyby mělo být všechno kontinuální? Jo, to by se pak asi hodně defragmentovalo, co?

Problém dynamických systémov je, že to kopiruje po celom disku, čo značne komplikuje následne obnovenie.

Usnadňuje, nekomplikuje. Navíc je Btrfs ve všech těchto ohledech lepší než Ext4, takže mi (zase!) není jasné, s čím srovnáváš a co bereš za vzor.

Hlavne pri nástrojoch ignorujúcich štruktúru fs.

A já jsem si myslel, že se bavíme hlavně o nástrojích specifických pro FS, které neignorují strukturu FS, když řešíme různé (nesmyslné) FUDy kolem Btrfs… Nebyla náhodou nejčastější (a stále opakovaná) výtka (asi tak v letech 2009 až 2013), že Btrfs prý nemá vhodné recovery nástroje?

Teď, když je má ve víc než hojné míře, je pořád něco špatně? Zase něco jiného? Tentokrát by měla být data obnovitelná bez nástrojů? Třeba i parita z raid6? Ta se má taky dát číst jen tak náhodně, bez specializovaných nástrojů? (dmraid tohle umožňuje? mdadm taky?) Tohle se jmenuje moving the goalposts. Chabý styl pseudo-argumentace.

Prečo nebojuješ proti rozdeleniu kernel a user memory space ? Alebo proti rozdeleniu v cpu ring. 0 až 3.

Ze stejného důvodu, proč nebojuju proti právům k souborům a proč nechci, aby každý uživatel měl přístup ke všemu, k čemu má přístup root.

Tady už vaříš z vody. Hotová ubohost. Sorry jako, falešné analogie jsou vždycky špatný nápad, v jakékoliv podobě.

Tu ide skôr o aktuálnosť. Nehovoríš, že všetko by malo byť aktuálne ?

Moje Btrfs je aktuální až na půdu. Kernel z roku 2015 by ho nenamountoval (naprosto správně), protože tam od té doby přibylo několik incompatibility bits.

Stejně tak na ZFS by člověk od té doby udělal několik zpool upgrade a starý kernel (nebo starý Solaris) by ho už taky nenamountoval.

Takže, co přesně nemám aktuální? Nějaké náměty k vylepšení? Důvod, proč jsem si metadata ještě nerebalancoval na raid1c3 nebo raid1c4 je zkrátka ten, že k tomu necítím potřebu. Zažil jsem selhání disku, měnil jsem disk za provozu, ale nikdy mi nepřišlo, že bych někde viděl Yetiho nebo write hole.

Možná na tom novém poli, které teď stavím, budu mít raid6 data a raid1c4 metadata. Pak to budu mít fakt úžasně aktuální. Možná taky ne. V každém případě to budu mít o několik řádů pravděpodobnosti selhání lepší než Ext4 + AID bez R.

[Aleš Kapica]

Heron má pravdu. Vím, že to rady některým dlouhobě nedochází (nazdar K3dare!) ale jediné, co do budoucna dává smysl, je nechat ty lidi ať se "vyškolí".

Moje zkušenost je taková, že jdou do sebe až je ztráta dat opravdu zabolí. Teprve pak si dají tu práci, přečtou dokumentaci a naučí se řešit svoje problémy sami, nebo slušně zaplatí někomu kdo to udělá za ně.

Snaha vyřešit každou volovinu na kterou se ptá kdejaký anonymní tupec vede jen k tomu, že se na internetu válí v diskuzích čím dál větší množství hnoje a tak se stává čím dál obtížnější najít skutečné řešení.

[Andrej]

…volovinu na kterou se ptá kdejaký anonymní tupec&helip;

Spíš než o řešení už tady jde spíš o „nepřičítání“ té voloviny Btrfs.

Ale takhle příkře bych to neviděl; zrovna tady se tazatel zaregistroval, stalo se mu (zjevně) něco nepříjemného s daty a z nějakého důvodu (mylný?) dojem, že to souvisí s Btrfs. Možná proto, že Btrfs je i po 10 letech běžné dostupnosti a běžného provozu pro některé „novinka“. Takže potud je otázka OK.

Jiná věc je, zda by se někdo takhle ptal, kdyby tam byl Ext4. Asi ne, protože Ext4 je přece „stabilní“, takže smí stabilně ztrácet data horem dolem, jak se mu zachce: [2009] [2012] [2015] [2018]

[k3dAR]

Heron má pravdu. Vím, že to rady některým dlouhobě nedochází (nazdar K3dare!) ale jediné, co do budoucna dává smysl, je nechat ty lidi ať se "vyškolí".[...]

Nazdar aLESI, to je dosti demagoidni, pokud tedy nechces AbcLinuxu poradnu uzavrit a misto toho si tu jen honit sve neanonimni tupe ego

[Aleš Kapica]

Nepoužívej slova kterým nerozumíš. Tvoje sdělení pak nedává žádný smysl.

Psát do poradny za každou cenu, jak to děláš ty, nevede tazatele k tomu, aby se nejdřív pokusil zamyslet a vyhledat na internetu jestli někdo náhodou stejný problém už neřešil. Osobně se ptám, jen když už nevím kudy kam.

Ty to možná tak nevnímáš, ale jsou dotazy, za kterými je skutečný problém. Pak jsou dotazy, za kterými je čirá lenost a pohodlnost, které sem pokládají ti, na kterými si podle tebe honím ego, ačkoliv ve skutečnosti chci většinou donutit dotyčného aby nejprve vyvinul trochu snahy. No a pak jsou dotazy záměrně provokující, na které reaguješ jen ty.

[k3dAR]

to uz sme "resili" ze jako egocentrik to neuznas, tak prestan aspon s teba traparnama ze tomu slovu nerozumim uz mas nejake zkusenosti, takze je logicke ze se nebudes ptat na kazdou (pro tebe) blbost, nicmene tvuj pristup ze me "nesnasis protoze se snazim lidem v poradne poradit", je ehm... a jiste nejde o zamerne provokujici dotazy, pokud tedy to neni "rafinovane" polozenej dotaz kterej zni realne a/nebo neodpovim s vedomim trotlovi, protoze si to muze precist nekdo normalni kdo na to pak narazi... kazdopadne u toho lekare uz jsi byl?

[Aleš Kapica]

nicmene tvuj pristup ze me "nesnasis protoze se snazim lidem v poradne poradit"

A to sis vycucal z kterého prstů? Jediný pocit který vůči tobě mám je hluboký soucit. A pokud jde o lékaře, jako pravidelný návštěvník tohoto serveru bys měl mít dostatečný přehled na to abys věděl že s povinností nosit držhubku skončily i zdravotní problémy co jsem měl. Stačilo jednou zajít do sauny.

[k3dAR]

to sem si necucal, to vicemene vypadlo letos nekde na abc z tebe sice sem myslel jineho lekare, ale dobre ze alespon tohle mas vyresene

[Aleš Kapica]

to sem si necucal, to vicemene vypadlo letos nekde na abc z tebe

Jo? Tak si dej tu práci a zkus to dohledat. Možná ti dojde, že to bylo myšleno trochu jinak a rozhodně ne tak osobně. Pokud mi teda nepřisuzuješ to, co na tvou adresu napsal jakýsi anonymní prudič.

A pokud jsi měl na mysli návštěvu psychiatra, tak tě mohu ujistit že to, na rozdíl od jiných emocionálně nevyrovnaných osob co se mi tu snaží nasazovat psí hlavu, nemám zapotřebí.

[k3dAR]

venoval sem dohledani 5minut nez sem to psal, vic mi prislo bezcene... radeji ti nadhodim par otazek:
Myslis ze poradna zde ma slouzit k porazeni?
Nemyslis si ze zacatecnik co si neumi najit odpoved na banalni problem je tupec?
Vadi ti kdyz nekdo nekomu poradi primo, misto aby ho "jen" nasmeroval?
Myslis ze mas vzdy pravdu?
Vadi ti kdyz napise ze nemas pravdu?
BTW: jeste sem nevidel psa egocentrika, takze se do psu nenavazej

[tupej trol]

Ja anonym a kdysi registrovany zacatecnik souhlasim s obema pristupy Kapicu chapu a tebe taky odivuju i Andreje a Herona. Co se tyce toho hnoje nebylo by naskodu obcasne procisteni ale to se stejne nestane.

[Heron]

Ovšem přesně tomuhle je důležité v debatách oponovat, když se takový nesmysl objeví.

No s tím v zásadě souhlasím. Ale otázkou je, jaký to má reálný dopad. Tohle se řeší i v propagaci vědy apod. Většinou se jen přesvědčují přesvědčení a na ty ostatní to moc velký dopad nemá.

Především proto, že kdyby tam nebyl mdadm (pseudo-RAID, ve skutečnosti AID, který by neměl existovat, měl by být označený za nebezpečný + deprecated atd.), nýbrž pouze Btrfs se svým vestavěným RAIDem, normálně by to ten systém ustál bez ztráty dat.

Souhlasím. V době vzniku toho jeho MD-RAID5 btrfs raid5 byl ještě v plenkách, takže to nebylo na stole. A do raid1 jsem ho nepřesvědčil. Osobně vůbec nemám rád paritní raidy, takže jen mirror nebo r10 a v tomto ohledu se mi velmi líbí RAID1C3, 3 kopie dat místo obvyklých dvou. Už se není potřeba bát v případě výpadku jednoho disku, že do konce recovery vypadne i další. Ale na tohle už ostatní moc neslyší. Raději zvolí raid-5 s tím, že jeden disk navíc vyřeší všechno.

[Andrej]

Většinou se jen přesvědčují přesvědčení a na ty ostatní to moc velký dopad nemá.

Existuje spousta lidí zvaných fence sitters. Nemají v dané oblasti dost znalostí, ale nemají ani dostatek hloupé ješitnosti na to, aby nekriticky přijali za své „jednoduché“ (a špatné) řešení. Jsou do značné míry přístupní argumentům. Čtou diskuse, ale málokdy se jich aktivně zúčastní. Na ně to může mít celkem podstatný pozitivní dopad.

Osobně vůbec nemám rád paritní raidy, takže jen mirror nebo r10 a v tomto ohledu se mi velmi líbí RAID1C3, 3 kopie dat místo obvyklých dvou. Už se není potřeba bát v případě výpadku jednoho disku, že do konce recovery vypadne i další.

Všechno má svá pro a proti. Na mém 8-diskovém RAID6 mám raději kapacitu 6 disků (RAID6) než kapacitu 4 disků (RAID1). Samozřejmě taková vypočítavost něco stojí. Nicméně faktem taky je, že moje pole (teoreticky, pokud se neposere nic dalšího) ustojí výpadek 2 disků, za cenu kapacity 2 disků, zatímco RAID1 pole (v terminologii Btrfs) by ustálo jenom výpadek 1 disku(*) (teoreticky, pokud se neposere nic dalšího), za cenu kapacity 4 disků. To je trochu drahé.

(*) U selhání 2 disků by to pořád nemusela být totální katastrofa; podstatná část dat, například malé soubory, které nakonec bývají jedny z nejdůležitějších, by se pořád ještě dala obnovit, protože pravděpodobnost, že by obě repliky jejich bloků byly zrovna (jenom) na těch dvou discích, které odešly, by byla příjemně nízká. Jenže pro větší soubory (jako třeba video) by byl výsledek tak či tak smutný.

[LarryL]

Většinou se jen přesvědčují přesvědčení a na ty ostatní to moc velký dopad nemá.

To si nemyslím. Lidé mají přirozený strach z nových věcí, které neznají nebo nepoužívají. Stačí když se o nových věcech, které lidi neznají diskutuje, oni se přestanou bát. Před cca 6 lety jsem se rozhodoval jestli použít EXT4, Btrfs nebo ZFS. Nakonec jsem se rozhodl pro EXT4, protože to byla stará známá škola. Dnes bych se díky podobných diskuzím jako tato nebál použít Btrfs.

PS: A pokud jde o vyložené nesmysly, tak pamatuj, že boj s lidskou hloupostí se sice nedá vyhrát, ale utéct z boje nemůžeš jinak blbost zaplaví svět - citát Jana Wericha ústy Jiřího Grygara - YT video

[Heron]

Lidé mají přirozený strach z nových věcí, které neznají nebo nepoužívají.

Myslím si, že tohle je jiné téma. Andrej hovořil o vyvracení nesmyslů. Pokud se někdo bojí nové technologie, lze na to v klidu reagovat tak, že si zůstane u toho, co mu funguje, že nemá zájem nebo čas zkoušel cokoliv nového (nebo že třeba ty nové vlastnosti ani nepoužije). Potud je to naprosto v pořádku.

Ovšem zde se bavíme o šíření nesmyslů. Kdy člověk, který dané nové technologii nerozumí a má ještě potřebu o ní šířit (zjednodušeně řečeno) pomluvy. A nemyslím si, že je úplně správná cesta nejdřív vyvracet všechny pomluvy, protože potom se v tom člověk utopí. Správná cesta je šířit kvalitní informace o té technologii. Jenže (a na to správně upozornil Aleš Kapica), vždy se v diskusi najde někdo, kdo především šíří kraviny a ta užitečná informace tam buď vůbec není, nebo je utopená.

A taky mi trochu nesedí ten strach. Proč by měl někdo z nového fs strach? Si jej může vyzkoušet, osahat, otestovat a potom třeba nasadit na méně důležitá data. Nebo třeba nenasadit, ale nechápu ten strach. Tyhle lidi nechápu, já jsem nadšený z každé nové technologie. Ne, že bych všechno používal, ale mám snahu si všechno osahat.

Jo, ta přednáška je skvělá.

[LarryL]

Proč by měl někdo z nového fs strach?

Strach ze ztráty dat nebo z komplikací, které by mohl nový fs přinést. O Btrfs jsem dříve uvažoval hlavně proto, abych mohl využívat na co jsem byl zvyklý z Win - bod obnovení. Když udělám upgrade Linuxu a on nenaběhne a zároveň nemám čas hledat řešení, tak abych se mohl rychle vrátit k předchozímu stavu. Případně pár dalších věcí co se mi u Btrfs/ZFS líbily, ale nejsem takový znalec file systémů, abych znal všechny rizika nového fs. Např. když disk s Btrfs přenesu do jiného PC, tak jestli nebude problém, nebo kombinace Btrfs a SSD, nebo u ZFS jsem měl strach, aby časem neužíral RAMku, případné problémy s šifrováním disku atd.

Si jej může vyzkoušet, osahat, otestovat a potom třeba nasadit na méně důležitá data.

Pokud vyzkouším, osahám a otestuji a zjistím, že je to OK, tak stejně pokud nebudu mít důvěru k Btrfs, tak nevím zda při upgradu Btrfs se něco nerozbije (nevím jak pečliví jsou vývojáři Btrfs). Tuhle důvěru získám tím, že si přečtu diskuze nebo články jakou zkušenost mají ostatní. No a když si přečtu diskuzi kde si někdo stěžuje, že mu btrfs poškodilo data a pak se v diskuzi ukáže, že za to Btrfs nemůže (a stejně tak by se to stalo s EXT4) tak se přesvědčím, že jsou to opravdu vůči Btrfs jen pomluvy. Jako souhlasím, že k těm pomluvám by vůbec dojít nemělo, ale když už dojde, tak by to ostatní co danému problému rozumějí měli vyvrátit.

Chci použít Btrfs zatím jen na "systém", takže to jsou méně důležitá data.

já jsem nadšený z každé nové technologie.

Tohle nadšení má asi většina mladých lidí, ale musí to být technologie, kterou člověk zná trochu více do hloubky nebo která není nijak kritická (např. nový prohlížeč).

[Aleš Kapica]

… Jako souhlasím, že k těm pomluvám by vůbec dojít nemělo, ale když už dojde, tak by to ostatní co danému problému rozumějí měli vyvrátit.

Boj s pomluvami je nekonečný. Vem si kolikrát už tady kolem Btrfs vzplanula podobná diskuze, kde se ti, co aktivně Btrfs používají, pokusili vysvětlit v čem se dotyčný mýlí a stejně se to objevuje zas a zas.

Je těžké si vybojovat vlastní cestu a jít proti všeobecné nedůvěře, pokud nemáš na své straně pádné argumenty. Ten můj byl jednoduchý – pokud mám ručit za spolehlivost, bude to po mém.

Dnes už nikdo nezpochybňuje, že jsem zvolil správnou cestu, protože tam kde mám Btrfs jsem za ta léta o data nikdy nepřišel – poprvé a naposledy jsem ztratil část dat v červenci 2012. Pak jsem přešel na diskless nad Btrfs.

[LarryL]

Boj s pomluvami je nekonečný...

To jo, ale jinak to nebude. Musíš bojovat dál . Ext4 je zaběhlý standard a ještě hodně krve proteče v diskuzních bitvách než se ustálí nový standard.

[Aleš Kapica]

Zřejmě jsi to blbě pochopil. Mně je to, na rozdíl od Andreje, ukradené. Pokud je někdo tak hloupý aby lpěl na horším řešení, tak mu to nebudu rozmlouvat. Ovšem pak se nemůže divit škodolibým poznámkám typu: "Já to říkal..."

Ale abychom si rozuměli, každý FS má svá specifika, takže jsou situace kdy i ext souborový systém dává smysl. Já ho kupř. používám pro half-diskless. Má nízkou režii, modul pro grub je pidi a nechci po něm nic než to, aby se dal rychle přečíst a sem tam do něj zapsat aktualizovaný ramdisk.

[Andrej]

Pokud je někdo tak hloupý aby lpěl na horším řešení, tak mu to nebudu rozmlouvat.

Vždyť já to přece nechci rozmlouvat jemu [tomu, kdo nechápe výhody Btfs / ZFS nad filesystémy z minulého století]. To nemá smysl a vůbec mi o to nejde.

Lidé, o které mi jde, jsou především ti v mlčící většině. Jsou to ti fence sitters, kteří si třeba diskusi přečtou. Pokud bude všude nakydaný blábol typu já se vracím k Ext4, já jsem to tušil, že Trabant je lepší než Rolls-Royce, ale nikdo proti tomu neřekne ani půl slova, můžou potom fence sitters zbytečně spadnout na (celkem objektivně) nesprávnou stranu plotu. Což sice není "můj problém", ale úplně lhostejné mi to taky není.

[k3dAR]

[...] Chci použít Btrfs zatím jen na "systém", takže to jsou méně důležitá data. [...]

btw: NEdoporucuju online prevod ext4=>btrfs, sice uz je to asi 1-2 roky co sem to zkusil a do tejdne se to zborilo, nicmene i nedavno zastanci BTRFS od tohoto prevodu odrazovali... takze jedine cistej btrfs format

[LarryL]

Mám dojem, že jsem o něčem takovém četl. Díky za připomenutí. Každopádně zvažuji i změnu distribuce, tak to vezmu všechno na čisto.

[Golis]

a pred snahou o recovery najprv musis obetovat tavu (velblouda) alebo staci sliepka (slepice)

[Andrej]

Jaká je tvoje pointa? Když odejdou všechny disky, co přesně od filesystému očekáváš? Zázraky? Když budeš obnovovat Ext4 z takové situace, budeš muset obětovat slona.

Před snahou o recovery platí úplně normální pravidla, která snad každému docvaknou: Pokud je to možné, stav disků to umožňuje a je na to volná kapacita, zazálohovat napřed binární obraz disků. (Ano, s RAIDem na úrovni filesystému by něco takového nemělo být potřeba, za normálních okolností, ale tady se nebavíme o normálních okolnostech.) Potom zkusit btrfs restore a uložit, co se dá. Pokud se souborový systém dá namountovat, samozřejmě zkusit jako první btrfs scrub. Pokud se nedá namountovat, následuje btrfs check, který může tvrdit, že nenašel filesystém, a v takovém případě mu bude předcházet ještě navíc btrfs rescue.

Selhání hardwaru nebo náhodné nízkoúrovňové zápisy na disk (vlivem lidské chyby nebo (jiného) selhání hardwaru) může do nečitelného stavu dostat kterýkoliv filesystém. Ten bez checksumů všech dat (například Ext4) bude ovšem mnohem rizikovější.

Mně tuhle například pád a reset během upgradu UEFI poškodil GPT, zničil celý UEFI oddíl (který už navíc v GPT nebyl) a zapsal kousek čehosi do Btrfs za tím. Obnova se podařila. Ale vyžadovalo to bootovací médium. Může za tohle Btrfs? Asi těžko. Bylo by to s Ext4 lepší? Asi těžko.

[Heron]

Před snahou o recovery by mělo předcházet vytažení záloh. Pokus o recovery si nechat jako kratochvíli na dlouhé zimní večery, pokud to člověka baví.

Přijde mi fascinující, jak někteří lidé hrotí ne/existenci různých nástrojů a jak moc nabořenej FS to ještě dokáže opravit. Bude někdo potom věřit těm datům, hlavně na FS bez checksumu?

Osobně recovery (nejen) FS vůbec neřeším. Pokud nastane problém, který vypadá trochu vážněji, tak sáhnu po zálohách. Je to rychlejší a spolehlivější.

[Andrej]

Mně tuhle například pád a reset během upgradu UEFI poškodil GPT, zničil celý UEFI oddíl (který už navíc v GPT nebyl) a zapsal kousek čehosi do Btrfs za tím. Obnova se podařila.

Před snahou o recovery by mělo předcházet vytažení záloh.
[…]
Osobně recovery (nejen) FS vůbec neřeším. Pokud nastane problém, který vypadá trochu vážněji, tak sáhnu po zálohách. Je to rychlejší a spolehlivější.

To sice jo, ale co už, když 2 poslední dny práce v zálohách chyběly. (A ano, dnes už vím, co dovede UEFI a jeho magické aplikace od výrobce, takže samozřejmě každému volání fwupdmgr upgrade předchází aktualizace záloh. Jo, kdybych to byl tenkrát věděl, ušetřilo by mi to [nedůležité] hodinu a [důležité] spoustu stresu. Nicméně něco takového jsem fakt nečekal. Nestalo se to nikdy předtím ani potom (Lenovo X1 Carbon 7. generace).)

Přijde mi fascinující, jak někteří lidé hrotí ne/existenci různých nástrojů a jak moc nabořenej FS to ještě dokáže opravit. Bude někdo potom věřit těm datům, hlavně na FS bez checksumu?

Taky bych se asi přikláněl spíš k novému vytvoření filesystému (poté, co člověk odstraní hardwarovou (nebo jinou) závadu, která problém způsobila). Stavový prostor možných chyb ve filesystému je prostě příliš velký. Nevěřím, že by nějaký tool dokázal (kterýkoliv) filesystém vždy opravit do zcela korektního stavu (byť třeba se ztrátou většiny dat). Může tam někde v metadatech zůstat cosi neobvyklého, co následně po letech způsobí spoustu trápení. Takže tady naprostý souhlas; pokud možno vytvořit FS znova.

[k3dAR]

pokud mas starsi fdisk, ten neumi gpt, takze jeste je sance ze zobrazi jen nejake nepouzite/zapomenute mbr, zkus parted:

sudo parted /dev/sdb print

vystup sem hod a pri vkladani ho oznac a tukni na <pre> abys zachoval formatovani textu...

a udelej to same s obouma diskama, jinak pokud se 3TB disk tvari ze jde o 750GB tak to na nebude vec BTRFS...

[jiwopene]

Tuším, že fdisk se dá přepnout na MBR pomocí M.

[k3dAR]

nevim co myslis, jestli prepnout jakoze zmenit disk z GPT na MBR, tak to pokud vim neumi, ale tazatel by to urcite nechtel, pokud myslis prepnout to co z disku zobrazuje, tak to by u novejsiho fdisku melo jit:

# zobrazeni jen gpt z disku
sudo fdisk -l gpt /dev/sdX -l

# zobrazeni jen mbr(/dos/msdos) z disku
sudo fdisk -l dos /dev/sdX -l

nicmene i tak bych spis pouzil parted nez spolehat na to jakou verzi fdisku ma :)

[k3dAR]

EDIT: oprava:

# zobrazeni jen gpt z disku
sudo fdisk -t gpt /dev/sdX -l

# zobrazeni jen mbr(/dos/msdos) z disku
sudo fdisk -t dos /dev/sdX -l

[Reclip]

Ahoj,

diky za koment, prikladam vystup, ale hazi to chybu.
Jeste me napadlo, jestli nemuze byt problem v tom, ze mam disk pripojen pres USB ze starsiho 1TB exteraku.
Jestli tam neni nejaky starsi radic, ktery si neporadi s 3TB diskem.
Tak jeste zkusim koupit novou dokovaci stanici. Ta se hodi vzdycky.

Jen podotykam, ze pracuji ve s Ubuntu ve virtualu.


sudo parted /dev/sdb print
Error: Invalid argument during seek for read on /dev/sdb
Retry/Ignore/Cancel? i                                                    
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? ok                                                             
Model: WD 30EFRX External (scsi)
Disk /dev/sdb: 802GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 

[pet I.]

Píšeš, že nejsi zdatný linuxák, a tak raději zdůrazním to nejdůležitější. Jestli chceš ta data opravdu zachránit, tak si napřed pořiď dva velké disky a zkopíruj si na ně obrazy těch původních disků pomocí programu ddrescue. Tím budeš mít "zakonzervovaný" stav a na kopiích z těchto dat můžeš dělat další pokusy. Jinak prvním neúspěšným pokusem můžeš obsah zničit definitivně.

[Reclip]

Ahoj,

diky za radu,
Ja prave delam jenom s jednim diskem, druhy nechavam lezet.
Byly v RAID 1.
Urcite bych nerad odpalil definitivne oba disky.

[Franta]

A jak víš, že ten"druhý" disk, který "necháváš ležet" jako zálohu, není ještě v horším stavu, než ten "první" disk, na kterém děláš pokusy? Co když data na něm jsou natolik poškozená, že z něj už nic nedostaneš? Být na tvém místě, udělám, jak ti bylo razeno výše, zálohu obou disků, a teprve potom bych činil pokusy o záchranu dat.

[Reclip]

Diky vsem za komenty a rady.

Jeste pridam nasledujici info:

zkousel jsem jeste nejake programy ve windows na zachranu dat. Problem je v tom, ze delaji primarne s ext4 a na btrfs se jaksi pozapomnelo.
Ale... Programy dokazi disk rozpoznat jako 3TB. UFS explorer RAID recovery dokonce naskenuje, vytahne i adresarovou strukturu.
Nicmene program je docela mastne zpoplatnen, takze zkousim najit jine bezboleste reseni. Na druhou stranu, pokud mi nic jineho nezbyde, tak budu muset cvakat, abych neprisel o data.
Takze aspon vim, ze data na disku jsou a ze jsou citelna, protoze program mi bezplatne nabidne i nahledy fotografii a o ty mi jde predevsim.

Dal jsme se dobrali k tomu, ze je asi poskozeno GPT, viz nasledujici vypis:
sudo parted /dev/sdb print
Error: Invalid argument during seek for read on /dev/sdb
Retry/Ignore/Cancel? i                                                    
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? ok                                                             
Model: WD 30EFRX External (scsi)
Disk /dev/sdb: 802GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags: 


Disk mam k PC pripojen pres extreni ramecek od stareho exteraku, kde byl 1TB disk, proto me jeste napadlo, jestli tam neni stary radic a zkusim koupit novou dokovaci stanici.

Pracuji v Ubuntu ve virtualu.

Predem diky za dalsi tipy.

[Vantomas]

Některé USB redukce mají problém s velkými disky, dokonce jsem narazil i na takové, které měly problém s GPT.

[k3dAR]

Heron to dobre shrnul, pokud ale mam odpovedet, chcesli to resit sam, tak rozhodne:
- vypustil bych ten nejistej ramecek
- vypustil bych nejistej virtual
- vypustil bych nejiste Windows
- pokud ti na datech zalezi, porid jam uz bylo napsano dalsi 2x 3TB, na ktere udelas 1:1 kopii POUZE s kterou budes pracovat, pokud by ti na nich jooo zalezelo bylo by vhodnejsi koupit 4x 3TB, a prvniho paru kopie udelat dalsi par kopie a pracovat az s tim, mel bys pak kdykoliv moznost se vratit s stavu prvni kopie bez toho aby si zapojoval zdrojove disky...

[k3dAR]

btw: nasledne treba postup od Synology: https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Storage/How_can_I_recover_data_from_my_DiskStation_using_a_PC
NEuvadej tam clon disku pres ddrescue, coz je to prvni co je potreba opravdu resit, pokud ti na datech zalezi (nechavam stranou ze v takovem pripade bys mel mit zalohu)...

[Aleš Kapica]

Prošel jsem si celou diskusi a radím vám jediné: Okamžitě zastavte jakékoliv pokusy a najděte si odborníka. Zejména, pokud jde o cenná data a nemáte jejich zálohu.

Původní dotaz vůbec nevysvětluje souvislost s BTRFS. Nevíme, zda se jedná o MD-RAID1 nebo o BTRFS-RAID1. Mluvíte o 3TB diskách, ale už v dotazu je 750GB. Na vině může být i převodník na USB, některé podporují jen 2TB disky a větší by se neměly ani připojit (je tedy divné, že z 3TB disku udělá 750GB).

Souvislost s BTRFS tedy (zatím) veškerá žádná. Doporučuju vám disky připojit k normálnímu řadiči na MB (ale ne toho NASu) a prozkoumat je tam. V první řadě by měla být vidět správná kapacita disku. Potom se podívat na GTP a na oddíly. Je možné, že to bude md-raid. Ten lze potom sestavit v degradovaném režimu (z jednoho disku) a připojit BTRFS FS. Pokud je tam rovnou BTRFS-RAID1, tak ten by šel připojit rovnou (s volbou ro,degraded).

[Max]

Já to pochopil tak, že má Synology, na kterém má BTRFS a v tom asi VM, který mu nestartuje, nevím. Každopádně Synology nepoužívá btrfs raid. Synology jede stále mdraid a nad tím pak formátuje na příslušný fs (a dělá to i s btrfs). Aspoń to tak tedy donedávna bylo.
Zdar Max

[Andrej]

Synology jede stále mdraid a nad tím pak formátuje na příslušný fs (a dělá to i s btrfs).

To by mělo být trestné.

[xxl]

Synology má na každém disku vytvořeno několik partition. Z prvních partitions na všech discích je vytvořen mdraid1 a na něm je systém. Z druhých partitions na všech discích je vytvořen mdraid1 a na něm je swap. Ty ostatní partitions slouží pro vytvoření dalších mdraidů (1, 5). A nad nimi je vytvořeno LV. V tom je v tomto případě konečně vytvořen jeden oddíl, na kterém je onen btrfs.

[k3dAR]

btw: mel to v Synology ktere pouziva BTRFS nad MDADM

[Reclip]

Dekuju moc vsem, co se tu VĚCNĚ vyjadrili a poradili.

Jinak jsem samozrejme hledal nejprve na netu, zkousel ruzne programy na zachranu atd.
Do poradny jsem psal predevsim proto, ze s linuxem v podstate nedelam a nez neco podelat uplne, radeji se zeptam odborniku.
To jsem si myslel, ze je smysl poradny. Poradit...
Sice nejsem uplny IT analfabet, ale s linuxem jsem delal naposled ve skole pred 15 lety, takze tak.
Chapu, ze podle nekterych bych mel nejdrive pul roku navstevovat vecerni skolu linuxu, vydat se az na konec internetu a pak sem teprve napsat.
Ja jsem z meho pohledu udelal maximum, nez jsem se na vas obratil. Tem, kterym to nestacilo se srdecne omlouvam.


Kazdopadne nejprve zkusim disk radne pripojit k PC, nez pres ten stavajici ramecek a pak zacnu postupovat podle rad. Chci nejprve zacit jen s "read only" resenim, nez se poustet do neceho dalsiho, pak uz by to opravdu stalo za to zazalohovat cely disk, nez se poustet do experimentu.

Jeste jednou diky vsem, co se mi snazili pomoct.

[Gréta]

voni sou hodný jenom maj strach žesi všecko smažeš nebo ten disk nějak jakoby dorazíš toje celý :D ;D

jinak kdyžuž to jako chceš dělat tak si nejdřiv udělej kopii toho disku hele třeba nóó a pak třeba zkusit zachraňovat z tý kopie photorecem hele :D ;D

[k3dAR]

s tim aby jako prvni udelal kopii, sem mu uz psal a nebyl sem sam, nicmene ocividne si mysli ze pracuje v "bezpecnem" "readonly" rezimu... a o opaku ho nepresvedci asi nikdo kdo mu chce/chtel poradit, ale az to kdyz se mu stav dat zhorsi a nevytahne uz nic...

[lertimir]

Ale ty uváděné kopirovací nástroje jsou vhodné, jen když je disk OK. Pokud je nabořen a v problémech, tak primárně ddrescue. Ten kolem narušeného disku dělá tanec mezi vejci. Když narazí na nečitelný sektor ihned o obskočí a čte v prvním kole, co jde lehce a bez problémů číst (copying), a teprve potom, až má přečtené, co šlo snadno, se vrací k problémovým částem a snaží se získat informaci odtud. Zase nejdříve revezním směrem od místa kde "při doskoku dopadl" (trimming) a finálně skáče dovnitř chybných oblastí (scraping), jestli tam něco použitelného nenajde.

už jsem viděl "dorazit" disk clonezillou. Ale samozřejmě připojit disk read only a snažit se ho číst, je větší čance ho dorazit.

[Gréta]

jj samože máš pravdu sem to trošičku nedomyslela :O ;D

[Petr Fiedler]

🐧