Administrace komentářů

PS: třeba mě nazvete lamou a BFU, ale btrfs mi nesmí do baráku - sem zase chtěl jít s dobou. Tohle se mi nestalo za celých 20 let s XFS a extX.

Prosím nešiř tady takový nesmyslný FUD. Tenhle problém nemá nic společného s Btrfs. (Kdyby se tohle stalo s oddílem s Ext4, sváděl bys to potom na Ext4? (Tipuju, že ne. Takže, nač ten dvojí metr?))

Souborový systém přece nemá žádnou kontrolu nad tím, co jsi udělal s tabulkou oddílů v nějakém starém Ubuntu, nebo nad tím, jestli ten oddíl máš nastavený jako hidden nebo něco podobně exotického, jestli sis náhodou nenastavil ignorování toho oddílu v udev pravidlech atd. atp.

Co říká udevadm monitor během připojování toho disku?

Když už máš možnost přečíst a zazálohovat tabulku GPT s přesnými hranicemi oddílů, co takhle zkusit celou tabulku smazat a znova vytvořit? Čistě jen tak pro ujištění, že v ní není nic špatného či neobvyklého. Ale rozhodně bych napřed zkusil udevadm monitor a udev obecně.

Pokud jde o UUID toho oddílu a pořadí bytů, stačí jenom nahlédnout do Wikipedie:

… The GUIDs in this table are written as per RFC 4122, i.e. big-endian byte order, recognizable by the position of the version bits. For example, the GUID for an EFI System partition (C12A7328-F81F-11D2-BA4B-00A0C93EC93B), when serialized in GPT data structures (little-endian), corresponds to the hex sequence 28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B. The first three blocks are byte-swapped to little-endian, the last is a byte array. …

Prý jsi chtěl jít s dobou… V roce 2019? Jo, kdybys používal Btrfs třeba v roce 2009, tenkrát bys možná šel s dobou. Dnes bych nutnou samozřejmost (tj. souborový systém s checksumy, RAIDem a copy-on-write) neoznačoval termínem "jít s dobou".

(Nedá se nic dělat; pro některé uživatele je ExtX se svým designem z 90. let (pro disky o velikosti jednotek GB), s absencí datových checksumů, snapshotů i RAIDu a se silent data corruption pořád jaksi záhadně atraktivní.)