Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Tiskni
Sdílej:
Jestli za kompletní vytuhnutí systému může poškozený btrfs, systemd nebo něco jiného, nevím.
Aha. Tohle^^^ by mohla být nakonec nejdůležitější věta celého blogpostu. 
Řekl bych ovšem, že tento problém s Btrfs opravdu může souviset. Samotná Btrfs WiKi to celkem jasně říká, cituji: „Stable kernel version 3.19.1+ can cause a deadlock at mount time … Fixed in 3.19.5, 3.14.39“
CentOS 7 má, jestli jeho weby a repository nekecají, nějaký prehistorický kernel 3.10 z července 2013. Je to sice dlouhodobě udržovaná verze, ale do takových dlouhodobě udržovaných verzí jdou většinou jen kritické bezpečnostní bugfixy. Vytuhnutí kernelu (ať už za něj může cokoliv) 3.10 je v roce 2016 irelevantní informace. Testovat na takovém kernelu cokoliv kolem filesystémů nedává valný smysl. Já bych na takovém kernelu asi nechtěl provozovat ani Ext4, čistě z toho důvodu, že právě Ext4 měl (na rozdíl od Btrfs) v posledních letech přehršel kritických bugů vedoucích k poškození dat a nikde není psáno, že se všechny opravy dostaly do všech starých kernelů.
Ještě v kernelu 3.13 jsou hlášené problémy s výkonem Btrfs v přítomnosti mnoha snapshotů a subvolumes — problémy, které už v daném „LTS“ kernelu nikdy nikdo neopraví. S kernelem 3.10 to asi nemůže být o moc lepší.
Tvrdit na základě kernelu 3.10, že Btrfs je nespolehlivý | špatný | pouhá pohádka | něco, co způsobuje zatuhnutí systému (byť na to v danou chvíli není žádný důkaz), je přinejmenším hodně přehnané.
Mimochodem, btrfs-zero-log nepomohl? 
(Já vím, někdy je snazší nic nehledat a svést to rovnou na Btrfs jako takový.)
Stable kernel version 3.19.1+ can cause a deadlock at mount time … Fixed in 3.19.5, 3.14.39“Takže pro btrfs je potřeba používat kernel typu RCx? Tak to potom jo...
BTRFS is a Technology Preview in Red Hat Enterprise Linux 7.Pro ty mene chapave Technology Preview == "muzete to zkusit, ale mozna vam to sezere boty.. a kdyz to ty boty sezere, udelame buga, a budeme mit soucit, ale to je asi tak vsechno" ;) Rekl bych ze BTRFS je trochu prilis velkej kus kodu, aby to nekdy v RHEL7 dotahl do produkcniho stavu.. nejdriv v RHEL 8 panove..
Chtěl jsem hlavně poukázat na nesmyslnost úvahy "kernel 3.10 - ježíšmarjá - to je prehistorie" a tvrzení, že se do jádra v enterprise distribucích dávají "většinou jen kritické bezpečnostní bugfixy". Třeba ve SLESu je BtrFS oficiálně podporovaný už od SLES 11 SP3, který má dokonce jádro 3.0 (BtrFS tam má ovšem k tomu z 3.0 dost daleko).
Na rovinu, kdybych chtěl mermomocí někde na produkční systém nasadit BtrFS, ke kódu ve SLE12 SP1 bych měl určitě víc důvěry než k upstreamovému 4.5.0 nebo 4.4.6.
Na rovinu, kdybych chtěl mermomocí někde na produkční systém nasadit BtrFS, ke kódu ve SLE12 SP1 bych měl určitě víc důvěry než k upstreamovému 4.5.0 nebo 4.4.6.
A to by byla chyba. Vznikl by z toho pak jen další blogpost podobný tomuto.
Myslím si, že Btrfs nikdo nechce nasadit „mermomocí“, ale kvůli killer features, které žádný jiný filesystém nemá, které zásadním způsobem zjednodušují údržbu systémů a zálohování a které ještě navíc posouvají odolnost proti silent data corruption na úplně novou úroveň. (ZFS má vše jmenované taktéž, ale není zrovna dvakrát mnoho distribucí, které ho podporují rovnou v instalátoru a které z něj bootují. Na FreeBSD je ZFS jasná volba, ale na Linuxu bych sázel spíš na Btrfs.)
právě Ext4 měl (na rozdíl od Btrfs) v posledních letech přehršel kritických bugů vedoucích k poškození dat a nikde není psáno, že se všechny opravy dostaly do všech starých kernelů.No jo, však ext4 taky není co se robustnosti týče zázrak století...
Tak jsem to vzdal, počkám tak pět let a zkoušet to budu na jiném, ne produkčním stroji.
Zatímco konkurence to celých těch pět let bude úspěšně provozovat na „produkčních“ strojích, stejně jako v uplynulých pěti letech. Inu, každý ať se rozhodne po svém. 
stejně jako v uplynulých pěti letechPred peti lety byl Btrfs max v pre-alpha stavu, takze bych rekl ze desive kecas...
Btrfs používám na všech svých strojích cca od ledna 2010. V pre-alpha stavu tenkrát rozhodně nebyl. To jen někteří zaspali dobu, podobně jako s IPv6 (což je protokol z roku 1995), s IPSec (který z nepochopitelných důvodů pořád ještě neposlal OpenVPN do propadliště dějin) a s několika dalšími technologiemi.
Výrok „nechci se učit nic nového“ člověk často slýchá ve zkomolené podobě typu „ono je to v pre-alpha stavu“, případně „ono je to možná nějak záhadně nekompatibilní s něčím dosud neznámým“ nebo ještě „ostatní to přece taky nemají“, což vede nakonec k jakési rekurzi.
21.3.2016 01:41
Max | skóre: 72
| blog: Max_Devaine
21.3.2016 06:48
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
21.3.2016 06:57
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Žádné testování na daném prostředí? Prostě hned tam nahrnout (ostrá) data?Jestli myslíš ostrými daty test zálohy virtuálů na btrfs, tak ano, byla to "ostrá" data. A k testování a "osahání" na daném prostředí myslím došlo...
Samozřejmě, mám zálohy a zálohy záloh a záložní "fail-over" PC, takže zas tak velký risk to nebyl. Jen jsem nečekal takové následky vzhledem k zde opěvovanému btrfs.
První nakopírování sparse kvm obrazů proběhlo pomocí příkazu cpTohle už by tě mělo natrknout. To že je soubor "děravý" je sice moc pěkné, ale poněkud nepraktické.
Za týden jsem se rozhodl upravit data pomocí rsync --inplace.To je moment, nad kterým je nutné se pozastavit. Btrfs je by default COW systém a pokud máš udělaný snapshot tak ti je nějaký rsync --inplace úplně k prdu, protože z hlediska FS ti vznikne úplně nový soubor. A i když byl původní soubor "děravý", teď se mohou na místě původních děr vyskytovat data . byť to je jen bordel, se kterým souborový systém virtuálu vůbec nepočítá - automaticky se to z obrazu disku totiž nevyhodí. No a teď si vezmi, že jsi díky parametru --inplace začal do původního souboru o určité velikosti s určitým checksumem rvát další data. To logicky nemohlo dopadnou dobře. Více by nám mohlo napovědět, co ti při tom systém vyzvracel do dmesgu, jenže to se už nedozvíme. Každpodádně následujícími kroky jsi tomu nijak nepomohl. Naopak. Sám píšeš, že nevíš, co ve skutečnosti může za vytuhnutí systému. Já ti napovím - tvoje blbost, protože - jinak by ses pokusil nejdřív zjistit, jaký proces ti žere nejvíc CPU, a případně nechal vypsat dmesg, ze kterého by ses mohl dozvědět, jestli ti nejde náhodou do kopru disk. Svádět to pak na FS je laciné a neopodstatněné. Já používám Btrfs již řadu let, dělal jsem s tím fakt hodně drsné věci, ale problém, že by nějakým způsobem zapříčinil vytuhnutí systému jsem měl pouze tehdy, když jsem rušil desetitisíce snapshotů subvolumes, které byly nasdílené přes NFS. A za vytuhnutím ve skutečnosti nebylo Btrfs, ale právě vyhnilý kernelový NFS server.
21.3.2016 21:23
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Mě tam spíš zaráží jiná věc. Pokud této události budeme říkat test (já bych tomu tak neříkal), tak na základě jednoho testu dělat závěry (a to ještě za situace, kdy vůbec nevíme, co je špatně) o dané technoligii je poněkud unáhlené.
Jinak co je špatně na sparse file na cow? Btrfs umí punch hole volání (FALLOC_FL_PUNCH_HOLE), sám mám 1TB sparse file exportovaný přes iscsi, iniciátor volá unmap a funguje to k všeobecné spokojenosti. Na straně inicitátoru je to 1TB disk (s nativním fs, toho času ntfs) a na straně targetu a btrfs to má aktuálně nějakých 31GB. Jestli rsync umí iteligentně přenášet sparse soubory a umí dělat díry, tak by to mělo fungovat. Včetně snapshotů.
21.3.2016 22:28
Cohen | skóre: 21
| blog: Drobnosti
| Brno
Sorry, ale ten způsob, jakým jsi hodlal dělat ty zálohy mi zavání totálním nepochopením problematiky.První nakopírování sparse kvm obrazů proběhlo pomocí příkazu cpTohle už by tě mělo natrknout. To že je soubor "děravý" je sice moc pěkné, ale poněkud nepraktické.
Sorry, ale já na tom nic špatného nevidím. Vylepšit by se to snad dalo jen o změnu za cp --sparse=always. Sice se ta iniciální děravost při přepisu zruší (viz dále), ale při iniciální kopii to data ušetří.
Za týden jsem se rozhodl upravit data pomocí rsync --inplace.To je moment, nad kterým je nutné se pozastavit. Btrfs je by default COW systém a pokud máš udělaný snapshot tak ti je nějaký rsync --inplace úplně k prdu, protože z hlediska FS ti vznikne úplně nový soubor.
Tak to určitě ne, to --inplace je tam právě proto, aby z toho nový soubor nevznikl, viz manuál rsync:
--inplace
This option changes how rsync transfers a file when its data needs to be updated: instead of the default method of creating a new copy of the file and moving it into place when it is complete, rsync instead writes the updated data directly to the destination file.
Sám to tak na zálohování na Btrfs používám. Respektive přidávám ještě rsync parametr --no-whole-file, což je důležité při kopírování z lokálního disku na lokální disk, kde se jinak zkopíruje celý soubor vedle původního, kterým se pak nahradí, což by nám rozbilo sdílení bloků přes Btrfs snapshoty.
A i když byl původní soubor "děravý", teď se mohou na místě původních děr vyskytovat data .
Navíc, jak se píše v manuálové stránce rsync, tak parametry --inplace a --sparse jsou konfiktní, tj. nejdou použít najednou.
byť to je jen bordel, se kterým souborový systém virtuálu vůbec nepočítá - automaticky se to z obrazu disku totiž nevyhodí.
Ano, to je samozřejmě další věc, že bez péče admina ty obrazy dlouho sparse nevydrží. O tom to ale nebylo. Šlo o to, že principielně na tom není nic, co by mělo nějak nefungovat nebo ničit data. Jen se musí počítat s tím, že díry, které nezabírají místo, v KVM obrazu moc dlouho nevydrží.
No a teď si vezmi, že jsi díky parametru --inplace začal do původního souboru o určité velikosti s určitým checksumem rvát další data. To logicky nemohlo dopadnou dobře.
Tak s tímto rozhodně nesouhlasím. Tohle je přece naprosto korektní postup práce se soubory, který nemůže nijak nijak poničit data – rsync zkrátka jen uvidím v souboru hodně nul („expanze“ díry v souboru), které případně korektně přepíše tím, co je nyní na daném místě ve zdrojovém souboru. Co to má co společného s jakým checksumem? Proč by to nemělo dopadnout dobře?
Tak to určitě ne, to --inplace je tam právě proto, aby z toho nový soubor nevzniklZda se ze nechapes co je COW, jak funguje Btrfs, a o cem ze mluvi ten pan... doporucuji si trochu nastudovat.
Tohle je přece naprosto korektní postup práce se souboryKorektni to mozna je, ale Btrfs ma jiste vlastnosti a kdyz zacnes delat veci ktere jdou proti nim, stane se presne to co se ti stalo - bude to trvat hodiny a akorat zabijes harddisk... Jak rikam, nastuduj si trochu Btrfs, COW a pribuzna temata, jinak to bude jen utrpeni pro tebe i hdd
22.3.2016 14:45
Cohen | skóre: 21
| blog: Drobnosti
| Brno
Tak to určitě ne, to --inplace je tam právě proto, aby z toho nový soubor nevzniklZda se ze nechapes co je COW, jak funguje Btrfs, a o cem ze mluvi ten pan... doporucuji si trochu nastudovat.
Spíš tahle reakce mi přijde mimo. V citované větě se mluví o parametru --inplace programu rsync a píše se tam, že když se použije, tak nevznikne nový soubor:
$ rsync source.vdi target.vdi & [1] 18816 $ ls -1 celkem 2893792 target.vdi .target.vdi.aFLNxM
To .target.vdi.aFLNxM je ten dočasný soubor, kam rsync kopíruje data, a až je tam má všechny, tak target.vdi smaže a .target.vdi.aFLNxM přejmenuje na target.vdi.
Když použiju --inplace, tak se to neděje, protože rsync celou dobu zapisuje jen do původního souboru, a když navíc použiju --no-whole-file, tak to navíc přepíše v původním souboru jen bloky, které se liší od souboru zdrojového. Co je stejné v source.vdi a targe.vdi, na to se nesáhne.
$ rsync --inplace --no-whole-file source.vdi target.vdi & [1] 18984 $ ls -1 target.vdi
Díky tomu mi krásně funguje CoW v Btrfs, protože se opravdu zapisují jen změněné kusy souboru a původní se nechávají netknuté. Tedy oproti poslednímu Btrfs snapshotu target.vdi se skutečně zapíšou jen změněné bloky, zbytek je na disku jen jednou sdílené mezi snapshotem/snapshoty a aktuální verzí. Přesně tedy využívám CoW vlastností Btrfs. Co je tedy na tom špatně a co jsem nepochopil?
Tohle je přece naprosto korektní postup práce se souboryKorektni to mozna je, ale Btrfs ma jiste vlastnosti a kdyz zacnes delat veci ktere jdou proti nim, stane se presne to co se ti stalo - bude to trvat hodiny a akorat zabijes harddisk... Jak rikam, nastuduj si trochu Btrfs, COW a pribuzna temata, jinak to bude jen utrpeni pro tebe i hdd
Tohle je naprostá hloupost. Proti žádným vlastnostem Btrfs nebo libovolného filesystému to nejde. A že to trvá dlouho, to je dáno těmi parametry --inplace --no-whole-file pro rsync, protože, jak jsme si ukázali výše, rsync musí postupně procházet celý veliký soubor a hledat, co je kde jinak (ne jen tupě zkopírovat všechno od začátku do konce), což dlouho trvá. S těmito parametry to ale tak dlouho bude trvat na libovolném filesystému, ne jen na Btrfs. Zbavit se těchto parametrů ale nemůžeme, pokud chceme využít CoW a neplýtvat místem a maximum dat držet sdílených mezi snapshoty.
Řešením by bylo nepoužívat rsync, ale btrfs send/receive, které právě proto Btrfs (a také ZFS) má. To ale předpokládá, že i zdroj dat je Btrfs subvolume.
No a teď si vezmi, že jsi díky parametru --inplace začal do původního souboru o určité velikosti s určitým checksumem rvát další data. To logicky nemohlo dopadnou dobře.Filesystému by mělo být úplně jedno, jaký soubor si otevřu a jaká data do něj budu rvát, minimálně z hlediska konzistence. Je možné, že tento postup není pro zálohy pomocí btrfs ideální, ale to nic nemění na tom, že slušný filesystém prostě musí běžné user-space operace nad fs bez problému zvládat (ať už je to
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
21.3.2016 14:07
rsync --inplace nebo něco jiného).
Svádět to pak na FS je laciné a neopodstatněné.Vzhledem k tomu, že problém nastal při mountu btrfs device, mi to až tak neopodstatněné nepřijde. Pokud se nejedná o hardwarový problém, pravděpodobnost, že na vině je btrfs mi přijde docela vysoká.
Vzhledem k tomu, že problém nastal při mountu btrfs deviceJá teda v zápisku čtu něco jiného:
Po tvrdém restartu systém bez problémů naběhl, aby po pěti sekundách opět "tiše vytuhnul".Vidím tam „pět sekund“ od naběhnutí systému. Netuším, co je okamžik naběhnutí systému (s takovou přesností, aby se od toho okamžiku dalo odměřit 5 sekund). Takže bych spíš řekl, že tazatel vaří z vody a nadává na věci, na které je moderní nadávat (všimněte si zmínky o systemd v zápisku). Zda je problém v mountování btrfs zařízení by se dalo snadno ověřit, nicméně autor zápisku to neudělal.
Musel jsem spustit live CD a zakomentovat v /etc/fstab připojení btrfs. Pak vše najelo bez problémů.
/etc/fstab napsaný špatně, nebo že se připojením oddílu spustil nějaký další kód (buď samotnou událostí připojení, nebo třeba nějaký startovací skript importoval nějaký skript z toho oddílu). A opět, netušíme, co s tím LiveCD vlastně prováděl – kdyby trochu tušil, co dělá, nebootuje žádné LiveCD, ale prostě by nabootoval systém do /bin/bash a /etc/fstab opravil odsud.
Jenom takhle od stolu mne napadá, že mohl mít /etc/fstab napsaný špatněJe nepravděpodobné, že by to způsobilo vytuhnutí systému.
nebo že se připojením oddílu spustil nějaký další kód (buď samotnou událostí připojení, nebo třeba nějaký startovací skript importoval nějaký skript z toho oddílu)Ditto, v takové situaci mi nepřijde pravděpodobné nic horšího než user-space segfault. A pokud se jedná jen o skript, pak ani ten segfault mi nepřijde pravděpodobný. Jinak ale technicky vzato máš pravdu, samozřejmě tam něco takového mohlo teoreticky nastat, nicméně pokud systém s řádkou ve fstab vytuhne a bez té jedné řádky nabootuje v pohodě, pak je IMHO zdaleka nejpravděpodobnější problém s mountovaným médiem, v té situaci bych podezíral selhání HW, a pokud by se ukázalo, že HW je v pořádku, hned další na řadě je chyba ve filesystému. Přesně takovouhle situaci jsem nedávno měl s F2FS. A jestli je moderní nebo cool nadávat na F2FS, tak už opravdu nevím
Je nepravděpodobné, že by to způsobilo vytuhnutí systému.Jenže já na základě toho zápisku nevidím nijak vysoko pravděpodobnost toho, že došlo k vytuhnutí systému.
22.3.2016 16:59
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Přišlo mi to, jako by ten virtuál při práci s tím souborem obcházel VFS hostitele.To jde? Teda za předpokladu, že ten virtuál neběží pod rootem a nemá přímý zapisovatelný přístup na disk (blokové zařízení), kde je ten soubor uložený?
Kdybych já přišel na to, že nějakej FS považovanej za stabilní a robustní se rozsypeJenže autor blogu na nic takového nepřišel. Autor blogu popsal, co dělal před vznikem problému, pak popsal projev samotného problému, nenapsal vůbec nic o tom, že by se pokoušel identifikovat příčinu problému, a na závěr to z ničeho nic hodil na btrfs. Já jsem na základě toho zápisku neztratil důvěru v btrfs, protože autor zápisku nezískal moji důvěru v tom, že je schopen alespoň základním způsobem analyzovat nějaký problém.
nějakej FS považovanej za stabilní a robustníNevim kdo ho povazuje za stabilni a robustni, ale
21.3.2016 22:22
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
22.3.2016 12:57
Ruža Becelin | skóre: 40
| blog: RuzaBecelinBlog
30.3.2016 12:13
Max | skóre: 72
| blog: Max_Devaine
btrfs má až DSM 6.0, který vyšel 24. 3. 2016. Předtím měl podporu btrfs asi jeden nový model, který vyšel někdy koncem loňského roku.
30.3.2016 22:58
Max | skóre: 72
| blog: Max_Devaine
btrfs je novinka verze 6.0, navíc je dostupná pouze pro vyšší modely.
btrfs check v aktuální verzi vyhazuje hromadu hlášek typu:
bad extent [3524147150848, 3524147167232), type mismatch with chunk bad extent [3524149575680, 3524149592064), type mismatch with chunk bad extent [3524149690368, 3524149706752), type mismatch with chunk bad extent [3524149788672, 3524149805056), type mismatch with chunk bad extent [3524149837824, 3524149854208), type mismatch with chunk bad extent [3524149870592, 3524149886976), type mismatch with chunk bad extent [3524149936128, 3524149952512), type mismatch with chunk bad extent [3524150050816, 3524150067200), type mismatch with chunk bad extent [3524150067200, 3524150083584), type mismatch with chunk bad extent [3524150083584, 3524150099968), type mismatch with chunk bad extent [3524150214656, 3524150231040), type mismatch with chunk bad extent [3524150231040, 3524150247424), type mismatch with chunk bad extent [3524150247424, 3524150263808), type mismatch with chunk bad extent [3524150263808, 3524150280192), type mismatch with chunk bad extent [3524150345728, 3524150362112), type mismatch with chunk bad extent [3524150444032, 3524150460416), type mismatch with chunk bad extent [3524150509568, 3524150525952), type mismatch with chunkZatím mi to dělaly všechny FS, které jsem zkoušel - a bezpečně vím, že se ještě před upgradem btrfs-progs tvářily jako čisté. Bohužel soudě podle výše uvedeného odkazu neexistuje možnost, jak takto poškozený filesystem opravit, jedině vytvořit ho znovu a přenést data (naštěstí funguje
btrfs send/receive, po přenosu cílový filesystem chyby nevykazuje). Netuším, jestli tenhle bug může způsobit nějakou ztrátu dat, ale než to riskovat, radši to u sebe předělám...
Jak to tak pozoruju, tenhle FS budu mít na blacklistu ještě hezky dlouho...
Souvislost s upgradem btrfs-progs bych viděl jako pravděpodobnější...