Dotaz: LUKS2 BTRFS OMV6 ztráta dat

[RDan]

Zdravím, napíšu to i sem.

Potřeboval bych prosím definitivní radu a potvrzení od odborníků přes Linux. Něco už vím, ale od začátku.

Mám: OMV6 (Debian) BTRFS RAID1c3 zašifrováno LUKS2.

1.0101 4.0201 7.0301
2.0102 5.0202 8.0302
3.0103 6.0203 9.0303
3x18TB 3x12TB 3x12TB

Sestavil jsem pole z disků 1,2,3 a zaplnil, přidal 4,5,6 a zaplnil a nakonec 7,8,9. Týdny to běželo a včera jsem restartoval kvůli aktualizaci biosu a od té doby disky 4,5,6 jsou prázdné. Gparted píše že jsou prázdné.

root@r-omv:~# sudo hexdump -C -n 512 /dev/sdg
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
root@r-omv:~# sudo hexdump -C -n 512 /dev/sdi
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
root@r-omv:~# sudo hexdump -C -n 512 /dev/sdl
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Podle tohodle tam nejsou LUKS hlavičky. Ale jak mohli zmizet po restartu?

Zálohované je nemám, protože jsem nevěděl že se to má dělat. Od Win95 jsem nikdy taky nezálohoval MBR u FAT32 nebo NTFS. Ani teď nezálohuju GPT u Win11.

Co je důležité, neprováděl jsem žádnou manipulaci s partitions na diskách nebo cokoliv jiného. Každý disk v trojici je jeden WD, Seagate a Toshiba. Takže to asi není selhání HDD. Potřeboval bych zprovoznit alespoň jeden z těch tří abych mohl dostat data ven.

Trochu doufám že LUKS2 má někde záložní hlavičku ale nepoznám to.

Také už jsem přemýšlel jestli to není nějaký Ransomware ale to bych asi někde měl viditelný info jak zaplatit výpalné. Také nemám server na venkovní síti a dobré heslo na Roota. Heslo k odemykání LUKS samozřejmě mám.

Prosím moc prosím o fundovanou radu, jde mi o 12TB dat a léta práce. Děkuji...

---

---

Odpovědi

[X]

https://forum.root.cz/index.php?topic=28404.msg398100;topicseen#new

Dobra rada. Nestav neco cemu nerozumis. Nemas LuksHeader zalohu? Smula, neudelas nic. Konec.

[RDan]

To není rada. Jsem si vědom ohledně zálohování na jiných místech a tak. Ovšem to je nad moje možnosti.

Moje otázka zní, jestli je definitivně konec dat nebo je možné ještě na disku najít nějakej záložní kus dat kterej by napomohl dešifrovat alespoň jedenoho disku.

A otázka jak se může stát že po restartu se ztratí hlavičky by možná pomohla i ostatním.

[X]

Moje otázka zní, jestli je definitivně konec dat nebo je možné ještě na disku najít nějakej záložní kus dat kterej by napomohl dešifrovat alespoň jedenoho disku.

RTFM

[Want]

Mluvíš z duše. Dělá divné věci a pak se diví.

[BFU]

Jsou opravdu prazdne cele, nebo na nich jenom chybi hlavicka ? Zkusil bych se podivat na prvni 16 MiB misto jenom prvnich 512 B .

Cteni /dev/sdX cte zacatek disku od offsetu 0, to je MBR, neni tam treba i /dev/sdX1 ? Vypise neco uzitecneho treba "$ fdisk -l /dev/sdg" nebo "$ gdisk -l /dev/sdg" (GPT je az za MBR a na konci disku, takze prvnich 512 B muze byt prazdnych) ?

Jestli je ten LUKS header nekde v partition, tak muze byt na nejakem vyssim offsetu, proto ty otazky.

[RDan]

root@r-omv:~# fdisk -l /dev/sdi
Disk /dev/sdi: 10,91 TiB, 12000138625024 bytes, 23437770752 sectors
Disk model: WDC WD121KRYZ-01
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

GPT fdisk (gdisk) version 1.0.6

Warning: Partition table header claims that the size of partition table
entries is 0 bytes, but this program  supports only 128-byte entries.
Adjusting accordingly, but partition table may be garbage.
Warning: Partition table header claims that the size of partition table
entries is 1055139364 bytes, but this program  supports only 128-byte entries.
Adjusting accordingly, but partition table may be garbage.
Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.
Disk /dev/sdi: 23437770752 sectors, 10.9 TiB
Model: WDC WD121KRYZ-01
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 22F27EB1-0E33-4824-A3FA-576A638A99BE
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 23437770718
Partitions will be aligned on 2048-sector boundaries
Total free space is 23437770685 sectors (10.9 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name


00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00400000  b4 3d 24 3a 48 68 26 70  72 3d 39 a2 10 f9 1f 47  |.=$:Hh&pr=9....G|
00400010  be 35 28 b2 e5 f9 1c bd  a8 28 8d 4e 7f d6 0d ea  |.5(......(.N....|
00400020  e9 d2 22 0b 99 3c 18 58  58 c6 04 4f 27 51 f0 ad  |.."..<.XX..O'Q..|
00400030  c1 76 40 92 ea f4 e4 ca  ac e4 b8 52 fa 23 03 fe  |.v@........R.#..|
00400040  2b 26 c7 2d f3 e4 a7 32  3e 68 b6 20 e9 a2 e4 a3  |+&.-...2>h. ....|
00400050  70 00 36 79 ee de a5 13  74 14 6c 30 f4 e4 c5 ea  |p.6y....t.l0....|
00400060  d9 02 76 88 94 1f f8 37  5b 7a b1 5d 6f 36 0f 3b  |..v....7[z.]o6.;|
00400070  60 90 20 b5 72 92 c8 9c  b9 2c 39 bc b3 e3 f9 87  |`. .r....,9.....|
00400080  7b e7 f0 35 04 39 4a af  a7 de 92 af 2b dd e0 b1  |{..5.9J.....+...|
.
.
.
.
.

Jsem si těmeř jistej že to bylo /dev/sdX protože tak jsou i ostatní. Dělal jsem přes GUI OMV6.

[BFU]

On je kazdy disk zasifrovany zvlast a teprve potom je z toho sestavene btrfs ?

Je mozne, ze cryptsetup pouziva nejakou luks hlavicku z jineho disku ?

Je zvlastni, ze tam chybi presne 4 MiB dat na zacatku, to vypada spise jako nejake zarovnani/alignment .

[RDan]

On je kazdy disk zasifrovany zvlast a teprve potom je z toho sestavene btrfs ? >No jasný, ale pod stejným heslem.

Je mozne, ze cryptsetup pouziva nejakou luks hlavicku z jineho disku ? >To netuším jestli to lze, ale já jsem pro to nic nedělal.

Je zvlastni, ze tam chybi presne 4 MiB dat na zacatku, to vypada spise jako nejake zarovnani/alignment . >A to jde za chodu když je filesystem připojen? Že by nějaký Ransomware?

[Want]

Nešálí mne zrak? Tys udělal Btrfs z kryptovaných blokových zařízení? Proboha proč?! To ses inspiroval reklamou na Foodoru, či co?

[RDan]

No BTRFS neumí zatím šifrování sám o sobě a tohle bylo doporučené řešení.

https://wiki.archlinux.org/title/btrfs Btrfs has no built-in encryption support, but this may come in the future. Users can encrypt the partition before running mkfs.btrfs.

[Want]

To že se to tak může udělat, neznamená, že je to dobrý nápad.

Tím, že Btrfs odřízneš od fyzického zařízení se připravíš o jeho nejsilnější zbraně. Je to cow FS. Takže si furt převaluje data sem a tam. Chápeš důsledky? Furt se něco kryptuje! A pokud je to v řádech terabajt.. no potěš koště. Ovšem co je nejdůležitější. Pokud se stane to co tobě, jsi v pytli, protože nemáš šanci zjistit co kde a jak dát dokupy. Je to příliš velký objem na to aby sis ho odsypal někam kde si můžeš hrát a stačí jedna neuvážená operace při které něco smažeš nebo přepíšeš. A jsi přesně tam kde jsi se ocitnul.

[Max]

Když chceš šifrovat, lepší možnost není. Mám to úplně stejně všude. Rizika s tím spojená je samozřejmě třeba brát v potaz.
Zdar Max

[X]

Urcite lepsi reseni je nespolehat se na jeden raid.

[Max]

To ale nikdo netvrdí. Tady se bavíme o šifrování.
Zdar Max

[X]

Bavime se o tom, ze tu mel pan btrfs raid na luksem a bylo mu to prd platny. Takze to "lepsi reseni" ma na OMV nejaky problem. Netvrdim, ze ten setup neni spatny, ale z tveho prizpevku neni poznat co tim "lepsim resenim" myslis.

[Max]

Hele, fakt nechápu, co není jasný. Tady někdo tvrdí, že tazatel nemá používat LUKS / šifrování, protože balablabla. Vzhledem k tomu, že btrfs nepodporuje šifrování, tak je to jediná možnost. Tj. zašifrovat blokové zařízení přes LUKS2 a nad to pak nahodit btrfs. To je celé. Zřejmě jsi tedy jen nepochopil, o čem je řeč / jak to funguje.
Zdar Max

[Andrej]

Tím, že Btrfs odřízneš od fyzického zařízení se připravíš o jeho nejsilnější zbraně. Je to cow FS. Takže si furt převaluje data sem a tam. Chápeš důsledky? Furt se něco kryptuje! A pokud je to v řádech terabajt.. no potěš koště. Ovšem co je nejdůležitější. Pokud se stane to co tobě, jsi v pytli, protože nemáš šanci zjistit co kde a jak dát dokupy. Je to příliš velký objem na to aby sis ho odsypal někam kde si můžeš hrát a stačí jedna neuvážená operace při které něco smažeš nebo přepíšeš. A jsi přesně tam kde jsi se ocitnul.

Plácáš tady totální, kolosální a monumentální nesmysly, navíc ještě s výstavní arogancí.

Samozřejmě, že Btrfs se dává na LUKS, jako ostatně kterýkoliv jiný souborový systém (bez vestavěné podpory pro šifrování; tu Btrfs zatím nemá).

Samozřejmě, že každé zařízení pod Btrfs musí být šifrované odděleně, protože „sjednocením“ těch zařízení do nějaké pofidérní AID vrstvy bez R (jako například dmraid / mdadm) by se Btrfs připravil o ty nejsilnější zbraně — tedy o skutečnou redundanci.

Škoda, že i skutečná redundance má své meze. Odolnost proti selhání 2 médií se selháním 3 médií mění v bezvýchodnou situaci za všech okolností. Tohle je právě ten důvod, proč mají existovat fyzicky oddělené zálohy. (Také s redundancí, také na Btrfs, také na LUKS, ale fyzicky oddělené, aby na ně nedosáhl tentýž požár, aby je nezpalavila tatáž povodeň atd.)

Résumé: Konfigurace, kterou popsal tazatel, byla rozumná a v nejlepším pořádku; není na ní nic v rozporu s „best practices“, „state of the něco“ atd. atp. Jenom zkrátka můžou přijít situace, které z principu ustát nemůže, a přesně taková situace bohužel nastala.

Takže si furt převaluje data sem a tam.

Prdlajs. Nevymýšlej si báchorky. Uživatel má plnou kontrolu nad tím, jestli a kdy a jak často chce souborový systém balancovat. Pokud se nemění stupeň redundance, počet médií ani jiná podstatná nastavení, k žádnému balancování (nebo co tím převalováním zkoušíš naznačit) není důvod. I když k němu nastane důvod, například po změně implicitního layoutu z raid6 na raid1c3, dejme tomu, nedochází k němu nikdy samovolně, natož furt.

[Max]

Naprostý souhlas.
Zdar Max

[Want]

Mas přečtený jeden článek a děláš machra ale víš o tom hovno, idiote!

[LarryL]

Tak napiš argumenty s čím přesně v Andrejově komentáři nesouhlasíš.

"Nebuďte sprostá, slečno!"

A radši nám řekni, jaké je tvoje řešení.

[Want]

Nestrkat penis do úle. Trubče!

[Andrej]

To je panečku výstavní idiůtek, tohleto. Není ani pořádný idiot, jenom idiůtek.

Takhle to vypadá, když mi někdo závidí znalost hovna, protože sám nezná ani to hovno.

[Want]

Tak předně. To, že zde rádi zneužívají anonymní nicky je stará známá věc, takže by sis měl uvědomit, že autor nikdy nemusí být týž.

A dále. Vím, že používáš Btrfs minimálně stejně dlouho jako já. A je velmi pravděpodobné, že se na rozdíl ode mne hrabeš i v jeho kódu. Nevím jak velké objemy dat na Btrfs skladuješ, ani jak divoké kombinace jsi s ním vyzkoušel, ale provozovat ho nad kryptovanými disky je koleda o průser. Mám doma několikaterabajtové pole, z různých disků na různých řadičích. A také dost zkušeností s infarktovými stavy, které naštěstí vždy dopadly dobře. Pro využití LUKSu jsem našel uplatnění až nyní a pochopitelně jsem se s ním nejdřív seznámil a pak ho řádně otestoval, než jsem ho implementoval. Moje motivace je ovšem jiná a stejně tak i způsob použití. Pracuji se soubory do 20GB s dekapitovanými hlavičkami, takže je na disku jen binární "bordel" Není tedy žádný důvod to komplikovat šifrováním pod Btrfs.

Z čistě praktického hlediska to považuji za potenciální zdroj komplikací. U Btrfs multidevice totiž není jedno které zařízení je zrovna nahoře, takže pokud se ti disky zpřehážou, můžeš mít problém. Mně to takhle dělá už několik let. Mám kvůli tomu SSH v ramdisku. Zůstane to totiž viset a následuje loterie, zda zařízení které se pokusím připojit je zrovna to správné. Fakt si nedovedu tedy představit, jak takovou věc řešit v kombinaci s kryptováním a to mám těch disků jen asi 12.

A pokud jde o to převalování. Opět praktické pozorování reálné situace. U terabajtového raidu, zaplněného z 90% by tomu mohlo být jen těžko jinak. Nebo mi snad chceš tvrdit, že se ty bloky nerekryptují, když děláš změny?

[Max]

Moc jsem nepobral to s tím přehazováním disků. Lze to nějak konkretizovat? Vždyť se běžně jede UUID identifikace, pořadí je mi putna. A je jedno, o co jde, zda o LUKS, FS, či další věci. Vše se skládá pomocí UUID identifikace. Pořadí čehokoli je tedy putna. Ale třeba jsem tě jen špatně pochopil.
Příklad s 90% zaplněním je také trochu divný. Best Practice u čehokoli je nejít nad 80%. Při enormním zaplnění pak samo může docházet k nadměrnému převalování dat, ale to už je stav, který si sám správce/uživatel přivodil.
Jinak v dnešní tobě několika TiB pole je celkem běžná věc, když existují 14TiB disky. Já mám třeba 4x6TB BTRFS RAID1C3 jen na hlouposti. Jinak na PC pak 2x1TB RAID1 a 3x8TB RAID1C2.
Vše šifrováno s LUKS2.
Zdar Max

[Ladik]

No jenze to UUID nemas "vypalene" na disku, je generovane z nejakych parametru disku - biosem nebo OS. A prave upgrade biosu ci linuxu to muze zmenit. Osobni zkusenost, po update RHEL6 na 7 se nam takhle zblaznili disky a pole jiz nenabehlo. Nastesti jsme pred upgrade udelali uplnou zalohu takze to byl jenom casovy problem.

[trubicoid2]

Čo také si, vojín Ladik, představujete pod "UUID je generovane z nejakych parametru disku - biosem nebo OS"?

UUID je zakódovaný až ve FS a vyrobí se tam při mkfs náhodně, nebo se dá změnit pomocí tune2fs -U či btrfstune -U

[Max]

Hele, UUID se generuje při vytváření něčeho. Tj. při vytváření FS, při vytváření LUKS, při vytváření LVM apod. a je uloženo v onom FS/LUKS apod. RHEL like OS jsem nikdy neupgradoval, vždy jen migroval. Co jsem ale vždy upgradoval, byl Arch a Debian, kde tento problém nikdy nenastal. Je na to rfc4122. Co ale třeba vím je, že RHEL like OS má třeba i jako parametr pro jádro cestu ke swapu a pokud se swap přesune někam jinam (nebo se odstraní úplně) a nezmění se zápis v grubu, tak OS nenabootuje.
Že by RHEL přegenerovával sám od sebe všechna UUID, to se mi moc nechce věřit (proč by to dělal?). Ale jak říkám, neznám upgrady v jeho světě.
Zdar Max

[Peter Golis]

Asi si chalan poplietol FS UUID (ktoré sa nemení), a HW WWID či čo. Ak mal pripojené disky z diskového poľa (cez FC/FCoE/iSCSI) alebo použil zle vyklonované pripravené disky, tak mu to mohlo zblbnúť.

Zrovna pri prechode z RHEL6 na RHEL7 na to zašal byť OS citlivejší. Ale to nie je chyba keď správca vynechá nejaké kroky keď to už ako-tak funguje (a vyrobí si časovanú bombu).

[Want]

No. Může se ti to zdát divné, ale je to tak. Kombinace co popisuješ jsou poměrně nekomplikované. Dokud to moje pole tvořily jen 4 x 2TB disky, taky nebyl problém.

[Max]

Stále bych byl rád, kdyby jsi to nějak konkretizoval. Říci, že se 4 disky problém není a s jiným počtem je, to je dost divné, na to, že se bavíme o naprosto základní funkcionalitě.
Zdar Max

[Aleš Kapica]

Rád bych ti vyhověl, ale fakt teď mám jiné starosti než vytahovat přes netconsoli log z domácího úložiště, kam jenom jednou za čas odsypu zálohy. Na to budu mít čas, až dodělám to co potřebuji a co se po mně chce. Ke konci roku jsem dokončil věc, ke které jsem se nemohl skoro dva roky dostat – a s tou mimo jiné souvisí i ty hrátky s LUKSem a Btrfs. Na blbosti budu mít čas až poběží semestr.

Ovšem abys neřekl. Na podobný problém jsme narazil v laborkách. Některé stroje začaly přehazovat bloková zařízení. Grub je vidí jako hd0 a hd1, ale když nastaruješ systém, mají některé stroje stejný disk jako /dev/sda a jiné /dev/sdb. Disklessu je to u prdele, ale mně to komplikuje práci, protože distribuovat systém na 20 počítačů ze kterých má 8 blokové zařízení přehozené jinak, je dost oser, protože si musíš hlídat každou konzoli. Zkusil jsem tedy přehodit kabely, jenže to zas nerozchodily jejich lokální MS Windows. Tak jsem se nakrknul, ty ostatní disky odpojil a je klid. Jeden disk, žádný problém.

Tak. A to byly ty disky jen dva. A než jsem tohle dopsal, vyprudilo mě to natolik, že jsem tedy ten stroj zapnul. Takže..

~ # cat /proc/partitions 
major minor  #blocks  name

   8       96 1953514584 sdg
   8       97 1953513560 sdg1
   8        0 1953514584 sda
   8        1 1953513543 sda1
   8      176 1953514584 sdl
   8      177 1953513560 sdl1
   8       64 1953514584 sde
   8       65 1953513560 sde1
   8       48 1953514584 sdd
   8       49 1953513543 sdd1
   8      112 1953514584 sdh
   8      113 1953513560 sdh1
   8      128  244198584 sdi
   8      129  244197560 sdi1
   8       32 7814026584 sdc
   8       33 7814025543 sdc1
   8       16 7814026584 sdb
   8       17 7814025543 sdb1
   8       80 1953514584 sdf
   8       81 1953513560 sdf1
   8      144  244198584 sdj
   8      145  244197560 sdj1
   8      160 1953514584 sdk
   8      161 1953513560 sdk1
~ # cat /proc/cmdline 
BOOT_IMAGE=/root/boot/vmlinuz-6.1.0-0-amd64 root=UUID=95ab0eec-4930-4400-8d89-4c24d6aa8f28 ro rootflags=subvol=root net.ifnames=0 biosdevname=0 pci=nomsi,noaer
~ # btrfs fi show
Label: 'main'  uuid: 10000000-0000-0000-0000-000000000000
        Total devices 10 FS bytes used 7.04TiB
        devid    1 size 1.82TiB used 1.40TiB path /dev/sdk1
        devid    2 size 1.82TiB used 1.38TiB path /dev/sdl1
        devid    8 size 1.82TiB used 1.16TiB path /dev/sda1
        devid    9 size 1.82TiB used 1.34TiB path /dev/sdd1
        devid   10 size 1.82TiB used 1.29TiB path /dev/sdh1
        devid   11 size 1.82TiB used 1.40TiB path /dev/sdf1
        devid   12 size 1.82TiB used 1.40TiB path /dev/sde1
        devid   13 size 1.82TiB used 1.38TiB path /dev/sdg1
        devid   16 size 7.28TiB used 1.90TiB path /dev/sdb1
        devid   17 size 7.28TiB used 1.44TiB path /dev/sdc1

Label: 'system'  uuid: 95ab0eec-4930-4400-8d89-4c24d6aa8f28
        Total devices 2 FS bytes used 55.58GiB
        devid    6 size 232.88GiB used 57.03GiB path /dev/sdi1
        devid    7 size 232.88GiB used 57.03GiB path /dev/sdj1
~ # mount LABEL=system /root -o subvol=root
mount: mounting /dev/sdj1 on /root failed: Invalid argument
~ # mount /dev/sdi1 /root -o subvol=root
~ # ls /root
bin             dev             home            initrd.img.old  lib64           mnt             proc            run             srv             tmp             var             vmlinuz.old
boot            etc             initrd.img      lib             media           opt             root            sbin            sys             usr             vmlinuz

Stačí? A ještě ti udělám reboot abys věděl o čem mluvím. Tentokrát se to chytlo napoprvé, ale systém stejně zůstal viset v ramdisku, jinak rovnou najel.

~ # cat /proc/partitions 
major minor  #blocks  name

   8       80  244198584 sdf
   8       81  244197560 sdf1
   8       64  244198584 sde
   8       65  244197560 sde1
   8       32 7814026584 sdc
   8       33 7814025543 sdc1
   8       48 1953514584 sdd
   8       49 1953513543 sdd1
   8        0 7814026584 sda
   8        1 7814025543 sda1
   8       16 1953514584 sdb
   8       17 1953513543 sdb1
   8      144 1953514584 sdj
   8      145 1953513560 sdj1
   8      112 1953514584 sdh
   8      113 1953513560 sdh1
   8      128 1953514584 sdi
   8      129 1953513560 sdi1
   8       96 1953514584 sdg
   8       97 1953513560 sdg1
   8      160 1953514584 sdk
   8      161 1953513560 sdk1
   8      176 1953514584 sdl
   8      177 1953513560 sdl1
~ # btrfs fi show
Label: 'system'  uuid: 95ab0eec-4930-4400-8d89-4c24d6aa8f28
        Total devices 2 FS bytes used 55.58GiB
        devid    6 size 232.88GiB used 57.03GiB path /dev/sde1
        devid    7 size 232.88GiB used 57.03GiB path /dev/sdf1

Label: 'main'  uuid: 10000000-0000-0000-0000-000000000000
        Total devices 10 FS bytes used 7.04TiB
        devid    1 size 1.82TiB used 1.40TiB path /dev/sdg1
        devid    2 size 1.82TiB used 1.38TiB path /dev/sdh1
        devid    8 size 1.82TiB used 1.16TiB path /dev/sdb1
        devid    9 size 1.82TiB used 1.34TiB path /dev/sdd1
        devid   10 size 1.82TiB used 1.29TiB path /dev/sdl1
        devid   11 size 1.82TiB used 1.40TiB path /dev/sdk1
        devid   12 size 1.82TiB used 1.40TiB path /dev/sdi1
        devid   13 size 1.82TiB used 1.38TiB path /dev/sdj1
        devid   16 size 7.28TiB used 1.90TiB path /dev/sda1
        devid   17 size 7.28TiB used 1.44TiB path /dev/sdc1

~ # mount UUID=95ab0eec-4930-4400-8d89-4c24d6aa8f28 /root -o subvol=root
~ # ls /root
bin             dev             home            initrd.img.old  lib64           mnt             proc            run             srv             tmp             var             vmlinuz.old
boot            etc             initrd.img      lib             media           opt             root            sbin            sys             usr             vmlinuz
~ # umount /root
~ # mount LABEL=system /root -o subvol=root
~ # mount
rootfs on / type rootfs (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=3995516k,nr_inodes=998879,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=813844k,mode=755,inode64)
none on /tmp/config type configfs (rw,relatime)
/dev/sde1 on /root type btrfs (rw,relatime,ssd,space_cache,subvolid=256,subvol=/root)

Takhle vypadá /etc/fstab

proc            /proc           proc    defaults        0       0
tmpfs           /tmp            tmpfs nodev,nosuid      0       0
UUID=95ab0eec-4930-4400-8d89-4c24d6aa8f28 / btrfs subvol=root 0 0
LABEL=main      /home   btrfs   subvol=home  0    2
LABEL=main      /mnt   btrfs   subvol=data  0    2

A spouštění vypadá tak, že se přihlásím přes dropbox, pokusím se udělat mount. A když se trefím tak udělám tohle:

   55 root     [xenbus_probe]
   56 root     [mld]
   57 root     [kworker/0:1H-kb]
   58 root     [ipv6_addrconf]
   63 root     [kstrp]
   68 root     [zswap-shrink]
   69 root     [kworker/u49:0]
  111 root     /lib/systemd/systemd-udevd --daemon --resolve-names=never
  135 root     [ata_sff]
  136 root     [scsi_eh_0]
  138 root     [scsi_tmf_0]
  139 root     [scsi_eh_1]
  141 root     [scsi_tmf_1]
  143 root     [scsi_eh_2]
  144 root     [scsi_eh_3]
  145 root     [scsi_tmf_2]
  146 root     [scsi_tmf_3]
  147 root     [scsi_eh_4]
  148 root     [scsi_eh_5]
  150 root     [scsi_tmf_5]
  151 root     [scsi_tmf_4]
  152 root     [scsi_eh_6]
  156 root     [scsi_tmf_6]
  157 root     [scsi_eh_7]
  158 root     [scsi_tmf_7]
  159 root     [scsi_eh_8]
  160 root     [scsi_tmf_8]
  161 root     [scsi_eh_9]
  162 root     [scsi_tmf_9]
  163 root     [kworker/u48:6-e]
  165 root     [scsi_eh_10]
  167 root     [scsi_tmf_10]
  170 root     [scsi_eh_11]
  171 root     [scsi_tmf_11]
  173 root     [scsi_eh_12]
  174 root     [scsi_tmf_12]
  175 root     [scsi_eh_13]
  176 root     [scsi_tmf_13]
  198 root     [kworker/1:3-mm_]
  201 root     [md]
  211 root     [raid5wq]
  229 root     /sbin/dropbear -EFs
  277 root     sh -i
  278 root     /sbin/dropbear -EFs -2 8
  279 root     -sh
  313 root     [btrfs-worker]
  314 root     [btrfs-worker-hi]
  315 root     [btrfs-delalloc]
  316 root     [btrfs-flush_del]
  317 root     [btrfs-cache]
  318 root     [btrfs-fixup]
  319 root     [btrfs-endio]
  320 root     [btrfs-endio-met]
  321 root     [btrfs-endio-rai]
  322 root     [btrfs-rmw]
  323 root     [btrfs-endio-wri]
  324 root     [btrfs-compresse]
  325 root     [btrfs-freespace]
  326 root     [btrfs-delayed-m]
  327 root     [btrfs-qgroup-re]
  328 root     [btrfs-cleaner]
  329 root     [btrfs-transacti]
  334 root     ps -ef
~ # kill -9 277

A systém najede

spike (SCHROT) :~# uptime
 00:58:51 up 12 min,  1 user,  load average: 0,68, 0,24, 0,08
spike (SCHROT) :~# date
Ne 14. ledna 2024, 00:58:54 CET

[Aleš Kapica]

Předem upozorňuji, že si jsem vědom toho, že je tam již starší jádro 6.1.0-0-amd64 (Debian 12.2.0-9). Jak si lze povšimnout z výpisu na stroji, je vidět, že všechny uuid zná, jenom ho ten správný zřejmě nemá tam, kde ho prioritně hledá. No tak se koukněme co vidí:

~ # blk
blkdiscard  blkid
~ # blkid 
/dev/sdf1: LABEL="main" UUID="10000000-0000-0000-0000-000000000000" UUID_SUB="7996bbee-83ee-4e14-9394-c02530ed1865" BLOCK_SIZE="4096" TYPE="btrfs" PTTYPE="dos" PARTUUID="2edaebd2-01"
/dev/sdd1: LABEL="system" UUID="95ab0eec-4930-4400-8d89-4c24d6aa8f28" UUID_SUB="ce3e665d-2e9f-4992-98ea-a0bfeb949585" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="0fd0cd04-01"
/dev/sdb1: LABEL="main" UUID="10000000-0000-0000-0000-000000000000" UUID_SUB="4b381c41-a01d-4caa-8ca5-de50c0675ef0" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="68920fba-6f75-4924-ac67-64488e5a0bc7"
/dev/sdk1: LABEL="main" UUID="10000000-0000-0000-0000-000000000000" UUID_SUB="aede2eaf-96bd-4db3-9b93-d48517344063" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="51a3f8d0-01"
/dev/sdi1: LABEL="main" UUID="10000000-0000-0000-0000-000000000000" UUID_SUB="7d036131-1c44-4b91-97a5-1f4d87acd908" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="7956c4ca-01"
/dev/sdg1: LABEL="main" UUID="10000000-0000-0000-0000-000000000000" UUID_SUB="765caf91-52e8-4aea-85f5-e03d68816dcd" BLOCK_SIZE="4096" TYPE="btrfs" PTTYPE="dos" PARTUUID="48190a45-01"
/dev/sde1: LABEL="system" UUID="95ab0eec-4930-4400-8d89-4c24d6aa8f28" UUID_SUB="508e10b8-eaa9-4d5e-b37e-3c5433ef9305" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="a76574ef-01"
/dev/sdc1: LABEL="main" UUID="10000000-0000-0000-0000-000000000000" UUID_SUB="c6dd2fe6-9da0-4955-b641-d7d6d3b3de67" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="7ea3eea8-69c1-4c7c-92e9-cc1fb697de51"
/dev/sdl1: LABEL="main" UUID="10000000-0000-0000-0000-000000000000" UUID_SUB="f2ccaaba-202b-4ab1-83d3-d8fe599d056a" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="5ef5c05a-01e6-4256-b676-8c9ccbba8c58"
/dev/sda1: LABEL="main" UUID="10000000-0000-0000-0000-000000000000" UUID_SUB="ed84105a-b5e7-4d5a-bd67-be09650e0a65" BLOCK_SIZE="4096" TYPE="btrfs" PARTLABEL="Linux filesystem" PARTUUID="efe48970-5db3-4409-b466-b5894a2bc3ff"
/dev/sdj1: LABEL="main" UUID="10000000-0000-0000-0000-000000000000" UUID_SUB="c5c5174d-31ea-4478-9111-d5f4f882a3cc" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="06e4ad3e-01"
/dev/sdh1: LABEL="main" UUID="10000000-0000-0000-0000-000000000000" UUID_SUB="da92ffb2-a1d8-419d-aad0-5fef997b49c0" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="ca9d1096-01"
~ # btrfs fi show
Label: 'main'  uuid: 10000000-0000-0000-0000-000000000000
        Total devices 10 FS bytes used 7.04TiB
        devid    1 size 1.82TiB used 1.40TiB path /dev/sdf1
        devid    2 size 1.82TiB used 1.38TiB path /dev/sdg1
        devid    8 size 1.82TiB used 1.16TiB path /dev/sdl1
        devid    9 size 1.82TiB used 1.34TiB path /dev/sdc1
        devid   10 size 1.82TiB used 1.29TiB path /dev/sdk1
        devid   11 size 1.82TiB used 1.40TiB path /dev/sdj1
        devid   12 size 1.82TiB used 1.40TiB path /dev/sdh1
        devid   13 size 1.82TiB used 1.38TiB path /dev/sdi1
        devid   16 size 7.28TiB used 1.90TiB path /dev/sdb1
        devid   17 size 7.28TiB used 1.44TiB path /dev/sda1

Label: 'system'  uuid: 95ab0eec-4930-4400-8d89-4c24d6aa8f28
        Total devices 2 FS bytes used 55.60GiB
        devid    6 size 232.88GiB used 57.03GiB path /dev/sdd1
        devid    7 size 232.88GiB used 57.03GiB path /dev/sde1

~ # mount LABEL=system /root -o subvol=root
mount: mounting /dev/sdd1 on /root failed: Invalid argument
~ # mount UUID=95ab0eec-4930-4400-8d89-4c24d6aa8f28 /root -o subvol=root
mount: mounting /dev/sdd1 on /root failed: Invalid argument
~ # mount /dev/sdd1 /root -o subvol=root
mount: mounting /dev/sdd1 on /root failed: Invalid argument
~ # mount /dev/sde1 /root -o subvol=root
~ # btrfs device stats /root
[/dev/sdd1].write_io_errs    0
[/dev/sdd1].read_io_errs     0
[/dev/sdd1].flush_io_errs    0
[/dev/sdd1].corruption_errs  0
[/dev/sdd1].generation_errs  0
[/dev/sde1].write_io_errs    0
[/dev/sde1].read_io_errs     0
[/dev/sde1].flush_io_errs    0
[/dev/sde1].corruption_errs  0
[/dev/sde1].generation_errs  0
~ # btrfs device usage /root
/dev/sdd1, ID: 6
   Device size:           232.88GiB
   Device slack:              0.00B
   Data,RAID1:             55.00GiB
   Metadata,RAID1:          2.00GiB
   System,RAID1:           32.00MiB
   Unallocated:           175.85GiB

/dev/sde1, ID: 7
   Device size:           232.88GiB
   Device slack:              0.00B
   Data,RAID1:             55.00GiB
   Metadata,RAID1:          2.00GiB
   System,RAID1:           32.00MiB
   Unallocated:           175.85GiB

~ # btrfs fi usage /root
Overall:
    Device size:                 465.77GiB
    Device allocated:            114.06GiB
    Device unallocated:          351.71GiB
    Device missing:                  0.00B
    Device slack:                    0.00B
    Used:                        111.21GiB
    Free (estimated):            176.27GiB      (min: 176.27GiB)
    Free (statfs, df):           176.27GiB
    Data ratio:                       2.00
    Metadata ratio:                   2.00
    Global reserve:              112.09MiB      (used: 0.00B)
    Multiple profiles:                  no

Data,RAID1: Size:55.00GiB, Used:54.58GiB (99.25%)
   /dev/sdd1      55.00GiB
   /dev/sde1      55.00GiB

Metadata,RAID1: Size:2.00GiB, Used:1.02GiB (50.96%)
   /dev/sdd1       2.00GiB
   /dev/sde1       2.00GiB

System,RAID1: Size:32.00MiB, Used:16.00KiB (0.05%)
   /dev/sdd1      32.00MiB
   /dev/sde1      32.00MiB

Unallocated:
   /dev/sdd1     175.85GiB
   /dev/sde1     175.85GiB
~ # btrfs scrub start /root
scrub started on /root, fsid 95ab0eec-4930-4400-8d89-4c24d6aa8f28 (pid=410)
~ # btrfs scrub status /root
UUID:             95ab0eec-4930-4400-8d89-4c24d6aa8f28
Scrub started:    Sun Jan 14 10:57:13 2024
Status:           running
Duration:         0:00:30
Time left:        0:02:23
ETA:              Sun Jan 14 11:00:10 2024
Total to scrub:   111.21GiB
Bytes scrubbed:   19.27GiB  (17.33%)
Rate:             657.80MiB/s
Error summary:    no errors found
~ # btrfs scrub status /root
UUID:             95ab0eec-4930-4400-8d89-4c24d6aa8f28
Scrub started:    Sun Jan 14 10:57:13 2024
Status:           finished
Duration:         0:03:31
Total to scrub:   111.21GiB
Rate:             539.70MiB/s
Error summary:    no errors found
~ # df -h
Filesystem                Size      Used Available Use% Mounted on
udev                      3.8G         0      3.8G   0% /dev
tmpfs                   794.8M    172.0K    794.6M   0% /run
/dev/sdd1               232.9G     55.7G    176.3G  24% /root

Jak si můžeš povšimnout, mount to tvrdošíjně zkouší přes UUID_SUB disku, který má v tuto chvíli označení /dev/sde, ale ve výpisu btrfs je vidět že by vyšší prioritu by mělo mít zařízení /dev/sdd. Takže to hledá asi někde jinde a jinak než by měl.

Také si všimni, že v režimu RAID1 jsou všechny bloky, tedy nejenom Data a Metadata, ale i System.

Jak vidíš, to pole není ani extra zaplněné. Obsazeno má pouhých 24%. A zcela na závěr jsem na to pustil scrub.

A také přihodím něco ze smartctl. Jak vidíš jsou to dva, relativně nové SSD disky – kdo si pozorně přečetl předchozí výpisy, tak si nepochybně všimnul automaticky přidaného atributu 'ssd' ve výpisu co vrací mount.

spike (SCHROT) :~# smartctl --all /dev/sdd1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-0-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 870 EVO 250GB
Serial Number:    S6PENL0T816723E
LU WWN Device Id: 5 002538 f5280e33c
Firmware Version: SVT02B6Q
User Capacity:    250 059 350 016 bytes [250 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic, zeroed
Device is:        In smartctl database 7.3/5319
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Sun Jan 14 12:09:19 2024 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

...

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       97
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       20
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       1
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   078   061   000    Old_age   Always       -       22
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   099   099   000    Old_age   Always       -       80
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       7
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       502287976
252 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%        11         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
  256        0    65535  Read_scanning was never started

...

spike (SCHROT) :~# smartctl --all /dev/sde1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-0-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 870 EVO 250GB
Serial Number:    S6PENL0T816709H
LU WWN Device Id: 5 002538 f5280e32e
Firmware Version: SVT02B6Q
User Capacity:    250 059 350 016 bytes [250 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
TRIM Command:     Available, deterministic, zeroed
Device is:        In smartctl database 7.3/5319
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Sun Jan 14 12:09:24 2024 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

...

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       97
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       20
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       1
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   078   059   000    Old_age   Always       -       22
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   099   099   000    Old_age   Always       -       84
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       6
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       491889128
252 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       1

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%        11         -
# 2  Extended offline    Aborted by host               90%         3         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
  256        0    65535  Read_scanning was never started

...

A protože mám už nastavené i to logování po síti, máš tady vše co v průběhu předchozích operací vyzvracel co syslogu. Včetněn těch DRDY chyb, o kterých už vím, že za nimi věcí SATA kabely.

[    2.461078] ata7.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[    2.461427] ata8.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[    8.579436] 
[    8.579532] 
[    8.579641] 
[    8.579748] 
[    8.580044] 
[    8.580309] 
[    8.580442] 
[    8.580554] 
[    8.594833] 
[    8.594967] 
[    8.718017] raid6: sse2x4   gen()  8360 MB/s
[    8.786015] raid6: sse2x2   gen()  8057 MB/s
[    8.854015] raid6: sse2x1   gen()  6559 MB/s
[    8.854089] raid6: using algorithm sse2x4 gen() 8360 MB/s
[    8.922019] raid6: .... xor() 2424 MB/s, rmw enabled
[    8.922092] raid6: using intx1 recovery algorithm
[    8.923171] xor: measuring software checksum speed
[    8.923962]    prefetch64-sse  : 13712 MB/sec
[    8.924797]    generic_sse     : 12894 MB/sec
[    8.924868] xor: using function: prefetch64-sse (13712 MB/sec)
[    8.925737] async_tx: api initialized (async)
[    9.504339] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, fsverity=yes
[    9.505331] BTRFS: device label system devid 6 transid 71812 /dev/sdd1 scanned by mount (252)
[    9.506175] BTRFS info (device sdd1): using crc32c (crc32c-generic) checksum algorithm
[    9.506268] BTRFS info (device sdd1): disk space caching is enabled
[    9.506867] BTRFS error (device sdd1): devid 7 uuid 508e10b8-eaa9-4d5e-b37e-3c5433ef9305 is missing
[    9.506943] BTRFS error (device sdd1): failed to read the system array: 1611046443
[    9.507265] BTRFS error (device sdd1): open_ctree failed
[   48.687444] [278] Jan 14 10:23:18 Child connection from 192.168.0.109:35880
[   48.688804] [278] Jan 14 10:23:18 Failed loading /etc/dropbear/dropbear_dss_host_key
[   48.688941] [278] Jan 14 10:23:18 Failed loading /etc/dropbear/dropbear_ed25519_host_key
[   48.764236] [278] Jan 14 10:23:18 Pubkey auth succeeded for 'root' with ssh-rsa key SHA256:2Dj1v+y6A8pvsxn0YPWRrcNFZhM4gcMQyfPWoznZpP0 from 192.168.0.109:35880
[   48.766311] [279] Jan 14 10:23:18 lastlog_perform_login: Couldn't stat /var/log/lastlog: No such file or directory
[   48.766434] [279] Jan 14 10:23:18 lastlog_openseek: /var/log/lastlog is not a file or directory!
[  597.896883] [302] Jan 14 10:32:28 Child connection from 176.65.145.210:53129
[  597.898291] [302] Jan 14 10:32:28 Failed loading /etc/dropbear/dropbear_dss_host_key
[  597.898455] [302] Jan 14 10:32:28 Failed loading /etc/dropbear/dropbear_ed25519_host_key
[  608.004924] [302] Jan 14 10:32:38 Exit before auth from <176.65.145.210:53129>: Exited normally
[  728.995993] BTRFS info (device sdd1): using crc32c (crc32c-generic) checksum algorithm
[  728.996109] BTRFS info (device sdd1): disk space caching is enabled
[  728.996602] BTRFS error (device sdd1): devid 7 uuid 508e10b8-eaa9-4d5e-b37e-3c5433ef9305 is missing
[  728.996706] BTRFS error (device sdd1): failed to read the system array: -1347562325
[  728.997064] BTRFS error (device sdd1): open_ctree failed
[ 1179.289718] BTRFS info (device sdd1): using crc32c (crc32c-generic) checksum algorithm
[ 1179.289834] BTRFS info (device sdd1): disk space caching is enabled
[ 1179.290356] BTRFS error (device sdd1): devid 7 uuid 508e10b8-eaa9-4d5e-b37e-3c5433ef9305 is missing
[ 1179.290456] BTRFS error (device sdd1): failed to read the system array: -1097625749
[ 1179.290803] BTRFS error (device sdd1): open_ctree failed
[ 1220.304528] BTRFS info (device sdd1): using crc32c (crc32c-generic) checksum algorithm
[ 1220.304659] BTRFS info (device sdd1): disk space caching is enabled
[ 1220.305198] BTRFS error (device sdd1): devid 7 uuid 508e10b8-eaa9-4d5e-b37e-3c5433ef9305 is missing
[ 1220.305297] BTRFS error (device sdd1): failed to read the system array: -1356172437
[ 1220.305650] BTRFS error (device sdd1): open_ctree failed
[ 1237.118467] BTRFS: device label system devid 7 transid 71812 /dev/sde1 scanned by mount (381)
[ 1237.123471] BTRFS info (device sdd1): using crc32c (crc32c-generic) checksum algorithm
[ 1237.123602] BTRFS info (device sdd1): disk space caching is enabled
[ 1237.146114] BTRFS info (device sdd1): enabling ssd optimizations
[ 2055.447996] [408] Jan 14 10:56:45 Child connection from 194.165.16.72:65321
[ 2055.449359] [408] Jan 14 10:56:45 Failed loading /etc/dropbear/dropbear_dss_host_key
[ 2055.449521] [408] Jan 14 10:56:45 Failed loading /etc/dropbear/dropbear_ed25519_host_key
[ 2055.450831] [408] Jan 14 10:56:45 Exit before auth from <194.165.16.72:65321>: Exited normally
[ 2083.378659] BTRFS info (device sdd1): scrub: started on devid 7
[ 2083.382451] BTRFS info (device sdd1): scrub: started on devid 6
[ 2084.509933] ata5.00: exception Emask 0x12 SAct 0x0 SErr 0x500 action 0x6 frozen
[ 2084.510037] ata5.00: irq_stat 0x08000000, interface fatal error
[ 2084.510124] ata5: SError: { UnrecovData Proto }
[ 2084.510213] ata5.00: failed command: READ DMA EXT
[ 2084.510291] ata5.00: cmd 25/00:00:80:74:0c/00:06:00:00:00/e0 tag 8 dma 786432 in
[ 2084.510291]          res 50/00:00:7f:74:0c/00:00:00:00:00/e0 Emask 0x12 (ATA bus error)
[ 2084.510435] ata5.00: status: { DRDY }
[ 2084.510529] ata5: hard resetting link
[ 2084.985967] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2084.986339] ata5.00: supports DRM functions and may not be fully accessible
[ 2084.989079] ata5.00: supports DRM functions and may not be fully accessible
[ 2084.991661] ata5.00: configured for UDMA/133
[ 2084.991778] ata5: EH complete
[ 2085.013811] ata5.00: Enabling discard_zeroes_data
[ 2114.493927] ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x400000 action 0x6 frozen
[ 2114.494032] ata6.00: irq_stat 0x08000000, interface fatal error
[ 2114.494117] ata6: SError: { Handshk }
[ 2114.494206] ata6.00: failed command: WRITE DMA EXT
[ 2114.494283] ata6.00: cmd 35/00:00:90:c0:6d/00:02:06:00:00/e0 tag 23 dma 262144 out
[ 2114.494283]          res 50/00:00:cf:31:3e/00:00:01:00:00/e0 Emask 0x10 (ATA bus error)
[ 2114.494427] ata6.00: status: { DRDY }
[ 2114.494520] ata6: hard resetting link
[ 2114.494609] ata5.00: exception Emask 0x10 SAct 0x0 SErr 0x400001 action 0x6 frozen
[ 2114.494715] ata5.00: irq_stat 0x08000000, interface fatal error
[ 2114.494793] ata5: SError: { RecovData Handshk }
[ 2114.494871] ata5.00: failed command: WRITE DMA EXT
[ 2114.494947] ata5.00: cmd 35/00:00:90:c0:cc/00:02:03:00:00/e0 tag 11 dma 262144 out
[ 2114.494947]          res 50/00:00:3f:27:82/00:00:00:00:00/e6 Emask 0x10 (ATA bus error)
[ 2114.495085] ata5.00: status: { DRDY }
[ 2114.495162] ata5: hard resetting link
[ 2114.969934] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2114.970055] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2114.970283] ata5.00: supports DRM functions and may not be fully accessible
[ 2114.970434] ata6.00: supports DRM functions and may not be fully accessible
[ 2114.973034] ata5.00: supports DRM functions and may not be fully accessible
[ 2114.973179] ata6.00: supports DRM functions and may not be fully accessible
[ 2114.975608] ata5.00: configured for UDMA/133
[ 2114.975721] ata5: EH complete
[ 2114.975828] ata6.00: configured for UDMA/133
[ 2114.975931] ata6: EH complete
[ 2114.989939] ata5.00: exception Emask 0x10 SAct 0x0 SErr 0x400000 action 0x6 frozen
[ 2114.990042] ata5.00: irq_stat 0x08000000, interface fatal error
[ 2114.990120] ata5: SError: { Handshk }
[ 2114.990200] ata5.00: failed command: WRITE DMA EXT
[ 2114.990280] ata5.00: cmd 35/00:00:90:c0:cc/00:02:03:00:00/e0 tag 28 dma 262144 out
[ 2114.990280]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
[ 2114.990421] ata5.00: status: { DRDY }
[ 2114.990502] ata5: hard resetting link
[ 2114.990601] ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x400000 action 0x6 frozen
[ 2114.990705] ata6.00: irq_stat 0x08000000, interface fatal error
[ 2114.990790] ata6: SError: { Handshk }
[ 2114.990872] ata6.00: failed command: WRITE DMA EXT
[ 2114.990956] ata6.00: cmd 35/00:00:90:c0:6d/00:02:06:00:00/e0 tag 25 dma 262144 out
[ 2114.990956]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
[ 2114.991098] ata6.00: status: { DRDY }
[ 2114.991191] ata6: hard resetting link
[ 2115.465923] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2115.466043] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2115.466268] ata5.00: supports DRM functions and may not be fully accessible
[ 2115.466418] ata6.00: supports DRM functions and may not be fully accessible
[ 2115.469005] ata5.00: supports DRM functions and may not be fully accessible
[ 2115.469154] ata6.00: supports DRM functions and may not be fully accessible
[ 2115.471634] ata5.00: configured for UDMA/133
[ 2115.471738] ata5: EH complete
[ 2115.471855] ata6.00: configured for UDMA/133
[ 2115.471972] ata6: EH complete
[ 2115.485929] ata5: limiting SATA link speed to 3.0 Gbps
[ 2115.486016] ata5.00: exception Emask 0x10 SAct 0x0 SErr 0x400000 action 0x6 frozen
[ 2115.486111] ata5.00: irq_stat 0x08000000, interface fatal error
[ 2115.486192] ata5: SError: { Handshk }
[ 2115.486271] ata5.00: failed command: WRITE DMA EXT
[ 2115.486351] ata5.00: cmd 35/00:00:90:c0:cc/00:02:03:00:00/e0 tag 13 dma 262144 out
[ 2115.486351]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
[ 2115.486490] ata5.00: status: { DRDY }
[ 2115.486570] ata5: hard resetting link
[ 2115.486671] ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x400000 action 0x6 frozen
[ 2115.486774] ata6.00: irq_stat 0x08000000, interface fatal error
[ 2115.486859] ata6: SError: { Handshk }
[ 2115.486941] ata6.00: failed command: WRITE DMA EXT
[ 2115.487024] ata6.00: cmd 35/00:00:90:c0:6d/00:02:06:00:00/e0 tag 7 dma 262144 out
[ 2115.487024]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
[ 2115.487167] ata6.00: status: { DRDY }
[ 2115.487260] ata6: hard resetting link
[ 2115.961923] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[ 2115.962044] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2115.962272] ata5.00: supports DRM functions and may not be fully accessible
[ 2115.962421] ata6.00: supports DRM functions and may not be fully accessible
[ 2115.965038] ata5.00: supports DRM functions and may not be fully accessible
[ 2115.965186] ata6.00: supports DRM functions and may not be fully accessible
[ 2115.967699] ata5.00: configured for UDMA/133
[ 2115.967797] ata5: EH complete
[ 2115.967878] ata6.00: configured for UDMA/133
[ 2115.967994] ata6: EH complete
[ 2115.974050] ata5.00: Enabling discard_zeroes_data
[ 2115.985920] ata6: limiting SATA link speed to 3.0 Gbps
[ 2115.986006] ata6.00: exception Emask 0x10 SAct 0x0 SErr 0x400000 action 0x6 frozen
[ 2115.986109] ata6.00: irq_stat 0x08000000, interface fatal error
[ 2115.986193] ata6: SError: { Handshk }
[ 2115.986275] ata6.00: failed command: WRITE DMA EXT
[ 2115.986357] ata6.00: cmd 35/00:00:90:c0:6d/00:02:06:00:00/e0 tag 9 dma 262144 out
[ 2115.986357]          res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
[ 2115.986500] ata6.00: status: { DRDY }
[ 2115.986593] ata6: hard resetting link
[ 2115.994117] ata5.00: Enabling discard_zeroes_data
[ 2116.461935] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[ 2116.462306] ata6.00: supports DRM functions and may not be fully accessible
[ 2116.465137] ata6.00: supports DRM functions and may not be fully accessible
[ 2116.467830] ata6.00: configured for UDMA/133
[ 2116.467935] ata6: EH complete
[ 2116.472491] ata6.00: Enabling discard_zeroes_data
[ 2116.491253] ata6.00: Enabling discard_zeroes_data
[ 2294.578891] BTRFS info (device sdd1): scrub: finished on devid 7 with status: 0
[ 2294.578892] BTRFS info (device sdd1): scrub: finished on devid 6 with status: 0
[ 2705.555080] Killed
[ 2705.555235] 
[ 2705.555330] 
[ 2705.555436] 
[ 2705.555532] 
[ 2705.555603] done.
[ 2705.555710] 
[ 2705.555824] 
[ 2705.555912] 
[ 2705.556016] 
[ 2734.310669] r8169 0000:07:00.0 eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 2734.310837] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 2747.762453] systemd-journald[502]: Successfully sent stream file descriptor to service manager.
[ 2814.343770] systemd-journald[502]: Sent WATCHDOG=1 notification.
[ 2924.344882] systemd-journald[502]: Sent WATCHDOG=1 notification.
[ 2994.345867] systemd-journald[502]: Sent WATCHDOG=1 notification.

Tak. Teď si představ, že by ty disky byly ještě šifrované. To by bylo peklo na druhou, protože ten komp nemá žádnou klávesnici. Jenom ethernetový drát a malý monitor na hdmi, abych viděl, co se zrovna děje. Důvod je prozaický. U klávesnice jsem si při nedávném úklidu vysál 'enter', což je poměrně dosti významná klávesa, takže skončila v elektroodpadu. A navíc mám podezření že u té desky odchází USB subsystém, protože jádro mělo při použití klávesnice tendenci panikařit. Konečné řešení jsem odkládal až na přechod na novější HW, ale když už jste mě vyprovokovali, můžete se vytasit s vlastními myšlenkovými pochody.

Konkrétně mne zajímá, kde je zakopaný pes podle Andreje, protože vím (jak už jsem napsal pod nickem Want) že má s Btrfs opravdu dlouholeté zkušenosti.

Používáš pro mnoho partition LABEL=main, pak podle něj připojuješ některé disky a divíš se, že to najde pokaždé něco jiného?

Sorry, už jsem z toho zblbnul.

[Aleš Kapica]

Bych řekl, ale mám pro to pochopení. Teď jsem zabil dvě hodiny rozborem toho výpisu co dal RDan k dispozici níže. Ach, jo. Chtělo by to více lhostejnosti k cizím problémům, ale občas si nemohu pomoct.

[LarryL]

~ # mount LABEL=system /root -o subvol=root
mount: mounting /dev/sdd1 on /root failed: Invalid argument
~ # mount UUID=95ab0eec-4930-4400-8d89-4c24d6aa8f28 /root -o subvol=root
mount: mounting /dev/sdd1 on /root failed: Invalid argument
~ # mount /dev/sdd1 /root -o subvol=root
mount: mounting /dev/sdd1 on /root failed: Invalid argument

Zkusil bych před mountováním použít příkaz: # btrfs device scan

U tvé distribuce se tento příkaz možná nespouští automaticky.

[Aleš Kapica]

Nejsem si jist. V ramdisku totiž končí vždy. Bez ohledu na to, jestli se pak ten mount podaří rovnou, nebo ne. A ve skriptu co je v ramdisku ten příkaz je:

~ # cat /scripts/local-premount/btrfs 
#!/bin/sh

set -e

PREREQ=""

prereqs()
{
        echo "${PREREQ}"
}

case "${1}" in
        prereqs)
                prereqs
                exit 0
                ;;
esac

if [ -x /bin/btrfs ]
then
#       modprobe btrfs
        # If asked to be quiet, show only errors
        [ "${quiet}" = "y" ] && exec >/dev/null
        /bin/btrfs device scan
fi

for i in $(/bin/btrfs fi show system | grep /dev | awk '{print $8}') ; do
        mount -n -t btrfs $i /root -o subvol=root
        sleep 1
        [ -d /root/bin ] && break || umount /root
        sleep 1
done

Ale možná jsi mne posunul k řešení. Distribuční skript u mne na notebooku totiž vypadá takto:

~$ cat /usr/share/initramfs-tools/scripts/local-premount/btrfs
#!/bin/sh

set -e

PREREQ=""

prereqs()
{
        echo "${PREREQ}"
}

case "${1}" in
        prereqs)
                prereqs
                exit 0
                ;;
esac

if [ -x /bin/btrfs ]
then
        modprobe btrfs ||:
        # If asked to be quiet, show only errors
        [ "${quiet}" = "y" ] && exec >/dev/null
        /bin/btrfs device scan
fi

A ten skript, který je v ramdisku je pouze nedotaženým řešením. S tím distribučním totiž ten systém nenajížděl vůbec. Zdá se, že v době kdy se ten skript spouští ještě sken disků není u konce, takže Btrfs ještě nic nevrátí. Dříve to fungovalo, protože původní init nespouštěl služby paralelně, ale postupně. Kdežto s nástupem systemd se na nic nečeká a tak je možné že se pokouší zpracovat lokální fstab dříve než má k dispozici všechny informace, proto se nic nepřipojí. A vynucené připojení přímo v tom skriptu mělo zajistit, že zavádění nemá pokračovat dřív, než pokud má k dispozici systém. Což jeden čas fungovalo. Jenže pak opět došlo k nějakým změnám a od té doby trvá ten problém.

[LarryL]

A ten skript, který je v ramdisku je pouze nedotaženým řešením.

Vy jste se v tom zase vrtal, pane doktore

S tím distribučním totiž ten systém nenajížděl vůbec.

To bude mít Andrej zase příležitost zkritizovat Debian a vychválit Arch. Už se těším

[Max]

A já budu mít také svou příležitost, protože Samsung SSD 870 EVO patří mezi ten nejhorší hw, na čem se dá Linux provozovat. Tolik bugů, silent data loss, bypass trimu (v rámci kernelu) a dalších věcí. Šílenost. Tím chci říci, že možná ani nebude problém v kabelu.
Každopádně až budu u svého PC, tak si zkusím pár rošád nasimulovat.
Zdar Max

[Want]

To je možné, že to je nejhorší typ SSD od Samsungu. Jak jsem zmínil, plánuji už několikátým rokem upgrade na novější HW, ale už jsem to několikrát posunul. Přednější je v tomto směru upgrade chrupu.

[Aleš Kapica]

Tím chci říci, že možná ani nebude problém v kabelu.

Problém je v kabeláži. To už mám dávno zjištěno. Problém je v tom, že moc na výběr nemám. Tenkrát, jak jsem marodil s tím kovidem, jsem to chtěl vyřešit novým řadičem a nakonec jsem byl rád, že jsem nepřišel o data a mohl ho vrátit. Vzhledem k tomu, že během posledních let došlo k rapidnímu navýšení kapacity rotačních disků, mám v úmyslu těch 8x 2TB (notebookové 2,5'' disky) nahradit za 4x 8TB, takže mi bude nová 8 portová deska stačit. A systém pojede ze 2x NVME disků. Jenže to už tím pádem znamená také nové CPU + nová RAM – ideálně ECC.

[xxl]

~ # mount LABEL=system /root -o subvol=root
mount: mounting /dev/sdd1 on /root failed: Invalid argument
~ # mount UUID=95ab0eec-4930-4400-8d89-4c24d6aa8f28 /root -o subvol=root
mount: mounting /dev/sdd1 on /root failed: Invalid argument
~ # mount /dev/sdd1 /root -o subvol=root
mount: mounting /dev/sdd1 on /root failed: Invalid argument
~ # mount /dev/sde1 /root -o subvol=root
~ # btrfs device stats /root
[/dev/sdd1].write_io_errs    0
[/dev/sdd1].read_io_errs     0
[/dev/sdd1].flush_io_errs    0
[/dev/sdd1].corruption_errs  0
[/dev/sdd1].generation_errs  0
[/dev/sde1].write_io_errs    0
[/dev/sde1].read_io_errs     0
[/dev/sde1].flush_io_errs    0
[/dev/sde1].corruption_errs  0
[/dev/sde1].generation_errs  0

Matně si pamatuji, že se mi kdysi nechtěl mountovat btrfs raid1 z jednoho fyzického disku, řekněme sdb1, zatímco z disku sda1 to bylo bez problémů. Když jsem mountoval pomocí uuid, tak to tedy fungovalo, ale ve výpisu byl vždycky jako namountovaný psaný ten jeden konkrétní fyzický disk. Různé blkid, lsblk, btrfs fi.... mi nic neporadily.

Já jsem o tom tenkrát věděl houby, takže žádné další poznatky nemám, než tuhle matnou vzpomínku. Jo, jeden poznatek ještě mám. Ten raid1 nebyl vytvářený rovnou pomocí mkfs.btrfs, ale postupně. Napřed to byl jeden samostatný disk, ke kterému jsem později ten druhý přidal.

[RDan]

Je zvlastni, ze tam chybi presne 4 MiB dat na zacatku, to vypada spise jako nejake zarovnani/alignment . >> A v těch 4 MiB datech je všechno důležité? Není to ještě někde jinde v záložním místě?

[BFU]

Skoro to tak vypada. Ty 4 MiB chybi na zacatku na vsech discich ?

Tady ten "cryptsetup repair" https://unix.stackexchange.com/questions/706070/restore-a-luks-partition-that-was-overwritten-by-pvcreate/706071#706071 a https://unix.stackexchange.com/questions/741404/overwritten-luks-with-a-partition-table/741850#741850 vypada docela rozumne (byl bych velmi opatrny se spoustenim prikazu, idealne pred kazdym prikazem procist manpage at to ty data neposkodi jeste vice). Obzvlast pozor na "wipefs" , to maze signatury filesystemu .

Jedna zajimava cast tam je "For LUKS1, it's usually game over, but LUKS2 has a secondary header at offset 0x4000." , takze luks2 ma kopii hlavicky, nicmene ta muze byt taky pryc. Dalsi zajimava cast je vyhledavani te luks hlavicky ve druhe casti "Metadata recovery:" -- "$ stdbuf -oL strings -n 64 -t d disk.img | grep '"keyslots":'" -- mozna to neco najde ? Tady to asi chce precist nejakych 128 MiB to souboru a pak na to pustit ten strings:

$ dd if=/dev/sdi of=/tmp/disk.img bs=1M count=128 ; stdbuf -oL strings -n 64 -t d /tmp/disk.img | grep '"keyslots":'

[RDan]

Chybý u všech tří, které jsem tehda přidával. btrfs device add /dev/mapper/sdE-crypt /dev/mapper/sdF-crypt /dev/mapper/sdG-crypt -f

Tím jsem si jistej, mám ještě v historii příkazů v bash.

Ale ty odkazy prozkoumám, asi zítra už. Zatím děkuju...

[RDan]

Trochu jsem to prozkoumal ale nevím jestli chápu souvislosti. Na tom webu tvoří EXT2 na loop1p1.

Ale já mám BTRFS na loop1.

Každopádně tohle mi vlévá trošku naděje:

root@r-omv:~# stdbuf -oL strings -n 64 -t d /tmp/Xdisk.img | grep '"keyslots":'
   4096 {"keyslots":{"0":{"type":"luks2","key_size":64,"af":{"type":"luks1","stripes":4000,"hash":"sha256"},"area":{"type":"raw","offset":"32768","size":"258048","encryption":"aes-xts-plain64","key_size":64},"kdf":{"type":"argon2i","time":10,"memory":1048576,"cpus":4,"salt":"3Hvtw5MjpKokqr8i3BMoPScv+r6808OX5bTMFTOxLpY="}}},"tokens":{},"segments":{"0":{"type":"crypt","offset":"16777216","size":"dynamic","iv_tweak":"0","encryption":"aes-xts-plain64","sector_size":512}},"digests":{"0":{"type":"pbkdf2","keyslots":["0"],"segments":["0"],"hash":"sha256","iterations":430449,"salt":"miKLdX79y9dioGdd6czImSSn33kaUjcuhR73yg6Yk88=","digest":"GYRbNwgGLAcc0vIj8oBr2MX7v/C74AaelTkqETaj+8s="}},"config":{"json_size":"12288","keyslots_size":"16744448"}}
  20480 {"keyslots":{"0":{"type":"luks2","key_size":64,"af":{"type":"luks1","stripes":4000,"hash":"sha256"},"area":{"type":"raw","offset":"32768","size":"258048","encryption":"aes-xts-plain64","key_size":64},"kdf":{"type":"argon2i","time":10,"memory":1048576,"cpus":4,"salt":"3Hvtw5MjpKokqr8i3BMoPScv+r6808OX5bTMFTOxLpY="}}},"tokens":{},"segments":{"0":{"type":"crypt","offset":"16777216","size":"dynamic","iv_tweak":"0","encryption":"aes-xts-plain64","sector_size":512}},"digests":{"0":{"type":"pbkdf2","keyslots":["0"],"segments":["0"],"hash":"sha256","iterations":430449,"salt":"miKLdX79y9dioGdd6czImSSn33kaUjcuhR73yg6Yk88=","digest":"GYRbNwgGLAcc0vIj8oBr2MX7v/C74AaelTkqETaj+8s="}},"config":{"json_size":"12288","keyslots_size":"16744448"}}

[RDan]

Aha, tak falešná naděje.

root@r-omv:~# dd if=/dev/sdg of=/tmp/diskX.img bs=1M count=128
128+0 záznamů přečteno
128+0 záznamů zapsáno
134217728 bajtů (134 MB, 128 MiB) zkopírováno, 0,521883 s, 257 MB/s
root@r-omv:~# stdbuf -oL strings -n 64 -t d /tmp/diskX.img | grep '"keyslots":'

[BFU]

Proc falesna nadeje ?

On na tom webu vytvori partitionu (/dev/loop1p1) co je zasifrovana a poskodi ji, aby pak demonstroval, jak ji obnovit.

V tomto pripade je asi zasifrovany cely disk (cca. equivalent /dev/loop1) .

Ono je to celkem jedno jestli je to cely disk nebo partition, oboji se chova jako blokove zarizeni.

...

Nejsou ty keysloty na nekterem jinem z tech tri disku ?

Co byl ten predchozi Xdisk.img ?

Co podobnym zpusobem zkontrolovat prvnich 128 MiB ostatnich disku, ty tam LUKS hlavicky maji ?

[RDan]

Ten první Xdisk.img byla právě už upravená

# truncate -s 128M disk.img
# losetup --find --show --partscan disk.img
/dev/loop0
# parted /dev/loop0 -- mklabel gpt
# parted /dev/loop0 -- mkpart luks $((RANDOM%100))MiB 100%
# cryptsetup luksFormat --type luks2 /dev/loop0p1

takže ty keysloty tam nejsou původně.

Taky tam tvoří EXT2, já bych to měl tedy nahradit BTRFS.

[RDan]

Tak kesloty nejsou ani na jednom z těch tří disků.

Jediná asi ještě možnost pokusit se dešifrovat data pomocí keyslotů z těch prvních disků, jako že je to nějak použilo.

[BFU]

Co podobnym zpusobem zkontrolovat prvnich 128 MiB ostatnich disku, ty tam LUKS hlavicky maji ?

Vypadaji ty hlavicky na kazdem disku (tam kde jsou) jinak, nebo jsou podobne/stejne ?

(rikam si, jestli se ty hlavicky nejak nerecyklujou)

[Peter Golis]

To mu už bolo dávno poradené.

I keď je moíné že OMV uložil posledne pridávaným diskom LUKS hlavičky externe (napr. niekam do /etc ako robí RHEL zálohu). A po update FW ich nehľadal. Síce je to malá pravdepodobnosť, ale je.

[RDan]

Zítra to porovnám a dám vědět.

A zkusím prohledat těch 128MB.

[Peter Golis]

Znovu by som odporučil skontrolovať ten "Master Key" pre rôzne zapojené disky v jednom OMV, tým hlavným kľúčom fyzicky šifruje disk. Ak sú zhodné, tak je to výhra v lotérii.

Ale to si mohol už dávnejšie.

[RDan]

Tak, napíšu co tu celé odpoledne dělám.

Zálohoval jsem si hlavičky z funkčních prvních HDD z těch původních 9. Zkusil pomoci nch otevřít ten zamčený disk bez hlavičky. Což se povedlo ve smyslu že to nenapsalo chybu a disk je /dev/mapper/sdi-crypt. Nicméně není na něm nic čitelného, takže předpokládám že ty data jsou šifrována jinými náhodnými klíči které se vygenerovali při tvorbě.

Také jsem stopoval v čase a došel jsem k tomu že mám logy z doby kdy jsem ty to pole tvořil. Ale bohužel v syslogu není vše. Dokonce jsem si na prázdném disku vytvořil nový LUKS2 ale v syslogu o tom není ani záznam. Takže tam není ani to z té doby kdy jsem tvořil to 9ti diskové pole. Což je škoda.

root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdk | grep "keyslot"
00001000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3122  {"keyslots":{"1"
000011f0: 6b65 7973 6c6f 7473 223a 5b22 3122 5d2c  keyslots":["1"],
000012c0: 222c 226b 6579 736c 6f74 735f 7369 7a65  ","keyslots_size
00005000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3122  {"keyslots":{"1"
000051f0: 6b65 7973 6c6f 7473 223a 5b22 3122 5d2c  keyslots":["1"],
000052c0: 222c 226b 6579 736c 6f74 735f 7369 7a65  ","keyslots_size
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdah | grep "keyslot"
00001000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3122  {"keyslots":{"1"
000011f0: 6b65 7973 6c6f 7473 223a 5b22 3122 5d2c  keyslots":["1"],
000012c0: 222c 226b 6579 736c 6f74 735f 7369 7a65  ","keyslots_size
00005000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3122  {"keyslots":{"1"
000051f0: 6b65 7973 6c6f 7473 223a 5b22 3122 5d2c  keyslots":["1"],
000052c0: 222c 226b 6579 736c 6f74 735f 7369 7a65  ","keyslots_size
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdac | grep "keyslot"
00001000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3122  {"keyslots":{"1"
000011f0: 6b65 7973 6c6f 7473 223a 5b22 3122 5d2c  keyslots":["1"],
000012c0: 222c 226b 6579 736c 6f74 735f 7369 7a65  ","keyslots_size
00005000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3122  {"keyslots":{"1"
000051f0: 6b65 7973 6c6f 7473 223a 5b22 3122 5d2c  keyslots":["1"],
000052c0: 222c 226b 6579 736c 6f74 735f 7369 7a65  ","keyslots_size
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdi | grep "keyslot"
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdl | grep "keyslot"
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdg | grep "keyslot"
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdj | grep "keyslot"
00001000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3022  {"keyslots":{"0"
000011f0: 226b 6579 736c 6f74 7322 3a5b 2230 225d  "keyslots":["0"]
000012c0: 3838 222c 226b 6579 736c 6f74 735f 7369  88","keyslots_si
00005000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3022  {"keyslots":{"0"
000051f0: 226b 6579 736c 6f74 7322 3a5b 2230 225d  "keyslots":["0"]
000052c0: 3838 222c 226b 6579 736c 6f74 735f 7369  88","keyslots_si
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdm | grep "keyslot"
00001000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3022  {"keyslots":{"0"
000011f0: 226b 6579 736c 6f74 7322 3a5b 2230 225d  "keyslots":["0"]
000012c0: 3838 222c 226b 6579 736c 6f74 735f 7369  88","keyslots_si
00005000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3022  {"keyslots":{"0"
000051f0: 226b 6579 736c 6f74 7322 3a5b 2230 225d  "keyslots":["0"]
000052c0: 3838 222c 226b 6579 736c 6f74 735f 7369  88","keyslots_si
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdb | grep "keyslot"
00001000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3022  {"keyslots":{"0"
000011f0: 226b 6579 736c 6f74 7322 3a5b 2230 225d  "keyslots":["0"]
000012c0: 3838 222c 226b 6579 736c 6f74 735f 7369  88","keyslots_si
00005000: 7b22 6b65 7973 6c6f 7473 223a 7b22 3022  {"keyslots":{"0"
000051f0: 226b 6579 736c 6f74 7322 3a5b 2230 225d  "keyslots":["0"]
000052c0: 3838 222c 226b 6579 736c 6f74 735f 7369  88","keyslots_si

root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdk | grep "luks"
00001010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
00005010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdah | grep "luks"
00001010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
00005010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdac | grep "luks"
00001010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
00005010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdi | grep "luks"
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdl | grep "luks"
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdg | grep "luks"
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdj | grep "luks"
00001010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
00005010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
02cb6050: 9cd1 59f9 6c75 6b73 ccb5 f058 72db a5ba  ..Y.luks...Xr...
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdm | grep "luks"
00001010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
00005010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
root@r-omv:~# sudo xxd -l $((128 * 1024 * 1024)) /dev/sdb | grep "luks"
00001010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"
00005010: 3a7b 2274 7970 6522 3a22 6c75 6b73 3222  :{"type":"luks2"

Zde je výpis všech 9 disků, hledání v prvních 128MB.

[Peter Golis]

Ono stačilo porovnať Master Key na dvoch zakryptovaných diskoch z toho jedného poľa v OMV, návod som linkoval. Slúži na to príkaz (z toho nalinkovaného návodu): cryptsetup luksDump --dump-master-key /dev/sdg

No, a to ti ukáže že tie kľúče sú rozdielne. O potrebe zálohovať tie hlavičky LUKS sa píše aj v doku pre openmediavault-luksencryption. On to sám nezálohuje.

Inak či si tam skúšal či tá obdoba RAID01 ustojí quick wipe (OMV pri quick wipe maže prvé 4MB disku) pre tri disky z jednej časti poľa, to už je zbytočné rozoberať. Ja by som preferoval RAID10 (teda to aspoň vybalansovať). Akurát by ma zaujímalo ako si dosiahol že si zadal jedno heslo jeden krát pre všetky disky naraz a nie pre každý disk zvlásť.

PS: Ja som sa bol prejsť, takých cca 15Km v mrazivom počasí vyčistí hlavu.

[RDan]

Pokud je to ta hodnota MK dump, tak ta je na každém disku jiná.

Dosáhl jsem toho tak že při vytváření toho LUKS přes GUI jsem prostě dal pokaždé stejné heslo.

Teď nerozumí jak to myslíš s tím RAID10. Jakože potom, až budu tvořit nové pole?

[RDan]

Mě to stejně pořád vrtá hlavou.

Když jsem to btrfs pole rozšiřoval, tak jsem použil /dev/mapper/sdX-crypt. To znamená že to bylo platně odemčené. A tím skončila jakákoliv manipulace těmi hdd. Takže buď to nějak ty hdd odemklo bez hlaviček, nebo se ztratily později i přes to že byli součástí připojeného BTRFS pole.

Fakt mi to hlava nebere.

[Peter Golis]

Bez hlavičiek to nemohlo odomknúť, ale mohlo si to pamätať staré nastavenie keď človek moc rýchlo vyklikával nastavenia a nepočkal na tú žltú bublinu. Takže to mohlo mať nabafrované rýchle vymazanie disku (makliknuté pred jeho pridaním do poľa), a po reboote sa to mohlo premazať pred zostavením už naplneného poľa. Ak to nebolo tým špecifickým updatom FW na HW.

A k tomu RAID01 versus RAID10, to je klasický príklad ktorý sa ukazuje na každom školení. Vyzerá to podobne, ale líši sa to počtom diskov ktoré môžu vypadnúť.

Inak mne vŕta hlavou akurát tak prečo si dal RAID Mirror cez tri disky na jedno NAS a vytvoriť tak Single Point of Failure, keď si mal možnosť tretinu diskov napchať do iného PC (hoci aj ako Virtuálny Počítač), a nechať si to tam raz za čas napchať a tú virtuálku vypnúť. To by si prišiel len o súbory a ich zmeny z času medzi synchronizáciou a haváriou a tie určite ešte na zdroji máš.

To, čo tam máš ma nezaujíma. Ja ten OMV testujem len na výkon a spoľahlivosť detekcie súkromných fotiek (klasifikácia objektov, detekcia miesta fotky, detekcia ksichtov a tak). Inak mi je to na prd, a na bežné veci používam samba share.

[RDan]

Zdá se že mount v degradovaném režimu na který jsem spoléhal alespoň pro zbytek dat má taky problém.

root@r-omv:~# sudo mount -o degraded -t btrfs /dev/disk/by-uuid/48e9afff-b502-469f-b737-c773605639a0 /srv/dev-disk-by-uuid-48e9afff-b502-469f-b737-c773605639a0 mount: /srv/dev-disk-by-uuid-48e9afff-b502-469f-b737-c773605639a0: wrong fs type, bad option, bad superblock on /dev/mapper/sdag-crypt, missing codepage or helper program, or other error.

A to už jsem ty disky pro jistotu připojil přes jinej řadič.

[Peter Golis]

Na výstupy z kódu sa zvykne používať tag PRE, ten zachováva aj riadkovanie. Lepšie sa to číta. A zvykne tam byť aj ďalší riadok s textom:

dmesg(1) may have more information after failed mount system call.

Teda že príkaz dmesg vypíše dôvod ktorý bránil pripojeniu. Odhadujem že je to tento:

BTRFS warning (device sda): writable mount is not allowed due to too many missing devices

Čo značí, že ti tam chýba parameter read only alebo podobne. Po jeho doplnení ti to pripojí zbytok BTRFS poľa, a časť súborov bude čitateľná.

[RDan]

root@r-omv:~# sudo mount -o degraded,ro -t btrfs /dev/disk/by-uuid/48e9afff-b502-469f-b737-c773605639a0 /srv/dev-disk-by-uuid-48e9afff-b502-469f-b737-c773605639a0
mount: /srv/dev-disk-by-uuid-48e9afff-b502-469f-b737-c773605639a0: wrong fs type, bad option, bad superblock on /dev/mapper/sdi-crypt, missing codepage or helper program, or other error.

[60277.066742] BTRFS info (device dm-15): using crc32c (crc32c-intel) checksum algorithm
[60277.066751] BTRFS info (device dm-15): allowing degraded mounts
[60277.066753] BTRFS info (device dm-15): disk space caching is enabled
[60279.603238] BTRFS warning (device dm-15): devid 4 uuid 3f891cd9-74e1-47d7-8208-a2cf38f8bacd is missing
[60279.603244] BTRFS warning (device dm-15): devid 5 uuid 18b05f84-8594-4854-8747-25bdd9a8700e is missing
[60279.603246] BTRFS warning (device dm-15): devid 6 uuid 6fe15784-fdfa-4e10-896a-831660edcc80 is missing
[60289.614753] BTRFS error (device dm-15): failed to verify dev extents against chunks: -5
[60290.389067] BTRFS error (device dm-15): open_ctree failed

Takto by to mělo být ale stejně.

[Peter Golis]

A nebeží tam teraz nejaká offline oprava ktorá by to pri pripájaní uzamkla kvôli prebiehajúcim zmenám (keď mu nesedia extenty)? Error 5 je input output error.

Pre istotu by som skontroloval či existuje ten prípojný bod v /srv na stroji kde je aktuálne ten disk, to je klasika.

[RDan]

No běží, ale chci ho nechat dokončit když už běží 12 hodin. Ale nešlo to ani předtím. Přípojný bod existuje a zkoušel jsem i jinej kterej jsem si udělal v /mnt/...

root@r-omv:~# btrfs rescue chunk-recover -y /dev/disk/by-uuid/48e9afff-b502-469f-b737-c773605639a0
Scanning: 7533247467520 in dev0, 11053066248192 in dev1, 11007280082944 in dev2, 7542182473728 in dev3, 7538590863360 in dev4, 10724943024128 in dev5

Už jsem to googlil ale HW chyba to není, připojil jsem to pro jistotu přes jinej řadič a disky jsou podle SMART v pořádku. A dokonce jsem zkusil odpojit ten první 18TB kdyby náhoudou.... ale stejné.

[RDan]

Tak jo teď bych teda fakt potřeboval pomoct jak připojit v degraded režimu.

root@r-omv:~# sudo mount -o degraded,ro -t btrfs -U 48e9afff-b502-469f-b737-c773605639a0 /srv/dev-disk-by-uuid-48e9afff-b502-469f-b737-c773605639a0
mount: /srv/dev-disk-by-uuid-48e9afff-b502-469f-b737-c773605639a0: wrong fs type, bad option, bad superblock on /dev/mapper/sdj-crypt, missing codepage or helper program, or other error.

[ 1520.477642] BTRFS info (device dm-0): using crc32c (crc32c-intel) checksum algorithm
[ 1520.477650] BTRFS info (device dm-0): allowing degraded mounts
[ 1520.477651] BTRFS info (device dm-0): disk space caching is enabled
[ 1520.480109] BTRFS warning (device dm-0): devid 4 uuid 3f891cd9-74e1-47d7-8208-a2cf38f8bacd is missing
[ 1520.480114] BTRFS warning (device dm-0): devid 5 uuid 18b05f84-8594-4854-8747-25bdd9a8700e is missing
[ 1520.480116] BTRFS warning (device dm-0): devid 6 uuid 6fe15784-fdfa-4e10-896a-831660edcc80 is missing
[ 1520.577558] BTRFS error (device dm-0): failed to verify dev extents against chunks: -5
[ 1520.586790] BTRFS error (device dm-0): open_ctree failed

Nic na pozadí neběží na těch diskách. A jsou odemčeny, ty zbývající.

Ta připojovací fráze by měla být správná ne?

[Peter Golis]

Tak možná trochu naděje, podařilo se namountovat.

root@r-omv:~# sudo mount -o ro,degraded,rescue=all -t btrfs -U 48e9afff-b502-469f-b737-c773605639a0 /srv/dev-disk-by-uuid-48e9afff-b502-469f-b737-c773605639a0

[LarryL]

Ja ten OMV testujem len na výkon a spoľahlivosť detekcie súkromných fotiek (klasifikácia objektov, detekcia miesta fotky, detekcia ksichtov a tak). Inak mi je to na prd, a na bežné veci používam samba share.

OT: Předpokládám, že detekci soukromých fotek nedělá samotný OMV, ale pluginy (PhotoPrism).

[Peter Golis]

V ňom áno. Vyzerá to rýchlejšie ako pri použití pluginov v nextcloud. Ale ešte to nedorobilo multimédiá za vyše 20 rokov, takže odchýľky v detekcii nemám ako porovnať.

[Peter Golis]

Tak mám výsledok.

PhotoPrism na OMV je oveľa rýchlejší pri práci na CPU, presnosť detekcie je podobná ako má NextCloud bez detailného nastavovania. A má to aj podobné limitácie pri automatickom a aj ručnom triedení podobných tvárí. Ale čo by sme chceli od SW ktorý nevyvíjajú trojpísmenkové agentúry, že áno.

Na domáce použitie je takmer jedno čo z toho človek na tento jeden špecifický účel použije.

[RDan]

Taky jsem hledal v syslogu jestli tam nebylo něco okolo toho vytváření LUKS disků nějaké upozornění. Ale nic jsem nenašel.

[RDan]

Prošel jsem si podrobně ty odkazy. Něco zkusil.

Ale já na těch vadných diskách nemám ani tu záložní hlavičku. A podle toho co jsem zjistil v té hlavičce jsou náhodné klíče vygenerované pomocí toho mého hesla. To znamená že ostatní disky i když jsou pod stejným heslem, nemají stejné dešifrovací klíče.

Je to tak? Takže definitivní ztráta?

[X]

Hexdump vypisuje bordel misto binarni hlavicky zacinanici magic retezcem "LUKS"..

[ewew]

Ako máš označené disky v /etc/crypttab ? Ak ich nemáš cez UUID je pravdepodné, že systém inicializoval jednotlivé disky v inom poradí. Toto je náhodný jav.

Spusti príkaz lsblk. Príkaz zobrazí blokové zariadenia a informácie o nich.

[RDan]

root@r-omv:~# lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda            8:0    0   5,5T  0 disk
sdb            8:16   0  10,9T  0 disk
└─sdb-crypt  253:4    0  10,9T  0 crypt
sdc            8:32   0   3,6T  0 disk
└─sdc-crypt  253:14   0   3,6T  0 crypt
sdd            8:48   0   5,5T  0 disk
└─sdd-crypt  253:11   0   5,5T  0 crypt
sde            8:64   0   5,5T  0 disk
└─sde-crypt  253:15   0   5,5T  0 crypt
sdf            8:80   0   3,6T  0 disk
└─sdf-crypt  253:7    0   3,6T  0 crypt /srv/dev-disk-by-uuid-b105c050-574b-4070-952b-68300159c431
sdg            8:96   0  10,9T  0 disk
sdh            8:112  0   3,6T  0 disk
└─sdh-crypt  253:12   0   3,6T  0 crypt
sdi            8:128  0  10,9T  0 disk
sdj            8:144  0  10,9T  0 disk
└─sdj-crypt  253:5    0  10,9T  0 crypt
sdk            8:160  0  16,4T  0 disk
└─sdk-crypt  253:2    0  16,4T  0 crypt
sdm            8:192  0  10,9T  0 disk
└─sdm-crypt  253:8    0  10,9T  0 crypt
sdn            8:208  0   2,7T  0 disk
└─sdn-crypt  253:13   0   2,7T  0 crypt
sdo            8:224  0   2,7T  0 disk
└─sdo-crypt  253:10   0   2,7T  0 crypt
sdp            8:240  0   2,7T  0 disk
└─sdp-crypt  253:6    0   2,7T  0 crypt /srv/dev-disk-by-uuid-f2f2eeee-2c5f-4289-b597-b18000c1ae05
sdq           65:0    0 931,5G  0 disk
└─md1          9:1    0   2,1T  0 raid0 /srv/dev-disk-by-uuid-d5cfecd9-41a1-4c97-a453-58a5a5064f99
sdr           65:16   0 931,5G  0 disk
└─md1          9:1    0   2,1T  0 raid0 /srv/dev-disk-by-uuid-d5cfecd9-41a1-4c97-a453-58a5a5064f99
sds           65:32   0 279,5G  0 disk
└─md1          9:1    0   2,1T  0 raid0 /srv/dev-disk-by-uuid-d5cfecd9-41a1-4c97-a453-58a5a5064f99
sdt           65:48   0   2,7T  0 disk  /srv/dev-disk-by-uuid-3c469e3d-3e09-45fe-b0eb-76cd0287938f
sdu           65:64   0   2,7T  0 disk  /srv/dev-disk-by-uuid-e35e7ea6-c7b6-4a8e-9904-159ef0610737
sdv           65:80   0   3,6T  0 disk  /srv/dev-disk-by-uuid-ba4491f0-3e1a-4314-9fc3-da6a1f324d8d
sdw           65:96   0   2,7T  0 disk  /srv/dev-disk-by-uuid-6b32b6e6-7ad6-4e26-a497-ed2d98b211d4
sdx           65:112  0   3,6T  0 disk  /srv/dev-disk-by-uuid-ecd2369c-99b3-4647-bb78-a43e62dc6232
sdy           65:128  0   3,6T  0 disk  /srv/dev-disk-by-uuid-b943a5ee-755c-4b6c-8d6d-6a0854406598
sdz           65:144  0   3,6T  0 disk  /srv/dev-disk-by-uuid-1e3ccde1-51a1-46bd-809e-c9ad59086d2e
sdaa          65:160  0   5,5T  0 disk  /srv/dev-disk-by-uuid-a9c6acc6-d611-4514-9141-5ca680793136
sdab          65:176  0   3,6T  0 disk  /srv/dev-disk-by-uuid-4ec6b146-32e4-4d0f-b1b1-886d0e239711
sdac          65:192  0  16,4T  0 disk
└─sdac-crypt 253:9    0  16,4T  0 crypt
sdad          65:208  0   3,6T  0 disk
└─sdad-crypt 253:0    0   3,6T  0 crypt
sdae          65:224  0   3,6T  0 disk
└─sdae-crypt 253:1    0   3,6T  0 crypt
sdaf          65:240  0 232,9G  0 disk
└─sdaf1       65:241  0 232,9G  0 part  /srv/dev-disk-by-uuid-6dba7e59-210e-4cd6-bde4-9df6894bf05d
sdag          66:0    0 119,2G  0 disk
└─sdag1       66:1    0 119,2G  0 part  /srv/dev-disk-by-uuid-2f4e25b2-df03-42bd-8c82-fe4dcc201344
sdah          66:16   0  16,4T  0 disk
└─sdah-crypt 253:3    0  16,4T  0 crypt
sdai          66:32   1  28,6G  0 disk
└─sdai1       66:33   1  28,6G  0 part
sdaj          66:48   0   3,6T  0 disk
sdak          66:64   0   3,6T  0 disk
sdal          66:80   0   3,6T  0 disk
sdam          66:96   0   3,6T  0 disk
sdan          66:112  0  10,9T  0 disk
nvme0n1      259:0    0 931,5G  0 disk  /srv/dev-disk-by-uuid-4d5fbc50-c661-471a-b311-ca1d8cbf9c07
nvme2n1      259:1    0 931,5G  0 disk
nvme1n1      259:2    0 465,8G  0 disk
├─nvme1n1p1  259:3    0   512M  0 part  /boot/efi
├─nvme1n1p2  259:4    0 464,3G  0 part  /
└─nvme1n1p3  259:5    0   976M  0 part  [SWAP]

V tomto výpise jsou to ty SDI, SDG s SDAN.

Crypttab je kupodivu prázdná. Ale OMV6 disky neodemyká automaticky. Musím to po startu udělat ručně. Ale o těch tře píše že nejsou LUKS.

[ewew]

Toto vyzerá na poprehadzované označenia diskov. Ako som písal. Je pravdepodobné, že disky sa inicializovali v inom poradí.

Podľa výpisu máš šifrované disky sdb,sdc,sdd,sdf,sdh,sdj,sdk,sdm,sdn,sdo,sdp,sdac,sdad,sdae,sdah.Ak máš ešte staré log súbory z /var/log/kern.log, tam by si mal mať informácie o detekcii diskov a ich prideleniu k /dev/sdX.

Zostáva ti len vyskúšať disky označné crypt, či ti ich odomkne a potom len skúšať či sú tam data. V prípade, že tam nemáš hlavičky, tak data sú nenávratne preč. Linux je postavený tak, že čo mu prikážeš to urobí, bez reči. Zálohu hlavičiek LUKS robí len ak to správca vyžiada.

Tady je ale vidět poněkud více disků, než jenom 9, o kterých mluvíš. Takto se ovšem z výpisu se dozvíš prd a my už tuplem. Ten příkaz má taky nějaké parametry, kterými se dá upravit, co chceš vypsat, aby se v tom dalo lépe vyznat.

[Aleš Kapica]

Jo. Každopádně je z toho jasné, že se nejedná o nějakou domácí mašinu, kterou by měl někde doma pod stolem, ale server do kterého je nacpaná pestrá směs minimálně 40 rotačních disků. A podle toho výpisu je v tom pěkný hegeš. Takže bych začal tím, že bych si vzal tužku, papír a udělal si jasno, který disk kam patří.

Osobně by mne zajímalo, co vyplivne takový příkaz btrfs fi show, protože jestli by našel alespoň něco, tak by u toho co mu chybí vyhodil missing a bylo by jasné co hledat dál. Jenže pokud nenajde nic, pak to znamená, že se nepodařilo odemknout nic z toho co je potřeba.

A možná jsem slepý, ale v tom výpisu nevidím 3x18TB, 3x12TB, 3x12TB, ale:

• 3x 2,1 TB v md raid 0 (fuj!)
• 3x kryptovaný 2,7TB – namountovaný
• 3x nekryptovaný 2,7TB
• 6x kryptovaných 3,6TB
• 9x nekryptovaný 3,6TB
• 2x kryptovaných 5,5TB
• 2x nekryptovaný 5,5TB
• 2x kryptovaných 10,9TB (nechybí jednomu z následujících disků LUKS hlavička?)
• 3x nekryptovaných 10,9TB
• 3x kryptovaných 16,4TB

Tj. 26 celkem + 2 standalone SSD + 1 USB + 1 missing = 40. Takže rozhodně nejde o výpis ze stroje, kterého se týkal původní dotaz.

1. disk /dev/sda má velikost 5,5 TB
2. kryptovaný disk /dev/sdb má velikost 3,6 TB
3. kryptovaný disk /dev/sdc má velikost 3,6 TB
4. kryptovaný disk /dev/sdd má velikost 5,5 TB
5. kryptovaný disk /dev/sde má velikost 5,5 TB
6. kryptovaný disk /dev/sdf je připojen na /srv/dev-disk-by-uuid-b105c050-574b-4070-952b-68300159c431 (má velikost 3,6)
7. disk /dev/sdg má velikost 10,9 TB
8. kryptovaný disk /dev/sdh má velikost 3,6 TB
9. disk /dev/sdi má velikost 10,9 TB
10. kryptovaný disk /dev/sdj má velikost 10,9 TB
11. kryptovaný disk /dev/sdk má velikost 16,4 TB
12. ??? /dev/sdl ???
13. kryptovaný disk /dev/sdm má velikost 10,9 TB
14. kryptovaný disk /dev/sdn má velikost 2,7 TB
15. kryptovaný disk /dev/sdo má velikost 2,7 TB
16. kryptovaný disk /dev/sdp je připojen na /srv/dev-disk-by-uuid-f2f2eeee-2c5f-4289-b597-b18000c1ae05 (má velikost 2,7 TB)
17. disk /dev/sdq je součást MD raidu 0 /srv/dev-disk-by-uuid-f2f2eeee-2c5f-4289-b597-b18000c1ae05 (raid má celkovou velikost 2,1 TB)
18. disk /dev/sdr je součást MD raidu 0 /srv/dev-disk-by-uuid-f2f2eeee-2c5f-4289-b597-b18000c1ae05 (raid má celkovou velikost 2,1 TB)
19. disk /dev/sds je součást MD raidu 0 /srv/dev-disk-by-uuid-f2f2eeee-2c5f-4289-b597-b18000c1ae05 (raid má celkovou velikost 2,1 TB)
20. disk /dev/sdt je připojen na /srv/dev-disk-by-uuid-3c469e3d-3e09-45fe-b0eb-76cd0287938f (má velikost 2,7 TB)
21. disk /dev/sdu je připojen na /srv/dev-disk-by-uuid-e35e7ea6-c7b6-4a8e-9904-159ef0610737 (má velikost 2,7 TB)
22. disk /dev/sdv je připojen na /srv/dev-disk-by-uuid-ba4491f0-3e1a-4314-9fc3-da6a1f324d8d (má velikost 3,6 TB)
23. disk /dev/sdw je připojen na /srv/dev-disk-by-uuid-6b32b6e6-7ad6-4e26-a497-ed2d98b211d4 (má velikost 2,7 TB)
24. disk /dev/sdx je připojen na /srv/dev-disk-by-uuid-ecd2369c-99b3-4647-bb78-a43e62dc6232 (má velikost 3,6 TB)
25. disk /dev/sdy je připojen na /srv/dev-disk-by-uuid-b943a5ee-755c-4b6c-8d6d-6a0854406598 (má velikost 3,6)
26. disk /dev/sdz je připojen na /srv/dev-disk-by-uuid-1e3ccde1-51a1-46bd-809e-c9ad59086d2e (má velikost 3,6 TB)
27. disk /dev/sdaa je připojen na /srv/dev-disk-by-uuid-a9c6acc6-d611-4514-9141-5ca680793136 (má velikost 5,5 TB)
28. disk /dev/sdab je připojen na /srv/dev-disk-by-uuid-4ec6b146-32e4-4d0f-b1b1-886d0e239711 (má velikost 3,6 TB)
29. kryptovaný disk /dev/sdac má velikost 16,4 TB
30. kryptovaný disk /dev/sdad má velikost 3,6 TB
31. kryptovaný disk /dev/sdae má velikost 3,6 TB
32. disk /dev/sdaf má vytvořen jeden diskový oddíl, připojený na /srv/dev-disk-by-uuid-6dba7e59-210e-4cd6-bde4-9df6894bf05d a protože má velikost pouhých 232,9G tipuji na SSD
33. disk /dev/sdag má vytvořen jeden diskový oddíl, připojený na /srv/dev-disk-by-uuid-2f4e25b2-df03-42bd-8c82-fe4dcc201344 a protože má velikost pouhých 119,2 tipuji na SSD
34. kryptovaný disk /dev/sdah (má velikost 16,4 TB)
35. disk /dev/sdai má velikost pouhých 28,6 GB a jeden diskový oddíl, takže to tipuji na zapíchnutou USB flashku
36. disk /dev/sdaj má velikost 3,6 TB
37. disk /dev/sdak má velikost 3,6 TB
38. disk /dev/sdal má velikost 3,6 TB
39. disk /dev/sdam má velikost 3,6 TB
40. disk /dev/sdan má velikost 10,9 TB

A pak tam jsou tři NVME disky, ale namountovány jsou jen dva, takže tipuji že ty dva i velikosti 931,5G jsou Btrfs v raid 1

1. /dev/nvme0n1 o velikosti 931,5G je připojený na /srv/dev-disk-by-uuid-4d5fbc50-c661-471a-b311-ca1d8cbf9c07
2. /dev/nvme1n1 je připojen na /srv/dev-disk-by-uuid-4d5fbc50-c661-471a-b311-ca1d8cbf9c07 (má velikost 465,8G)
3. /dev/nvme2n1 o velikosti 931,5G připojený není

[Aleš Kapica]

Takže rozhodně nejde o výpis ze stroje, kterého se týkal původní dotaz.

Poněkud jsem se unáhlil. Očividně 18TB je reálně 16,4 TB a 12TB je reálně 10,9 TB. Takže to vypadá, že ten chybějící disk /dev/sdl bude nejspíš jeden kryptovaný 10,9TB. V takovém případě by měl ovšem příkaz, který jsem již uvedl, vypsat co chybí a také které z těch kryptovaných zařízení je aktuálně nahoře. A pak by se s parametr degraded mělo dát to pole namountovat. Ale pochopitelně přes UUID-SUB toho disku co je aktuálně nahoře. Viz můj problém výše.

[RDan]

Pěkná analýza :)

root@r-omv:~# sudo btrfs filesystem show
Label: 'SSD-RAID0'  uuid: 4d5fbc50-c661-471a-b311-ca1d8cbf9c07
        Total devices 2 FS bytes used 579.79GiB
        devid    1 size 931.51GiB used 302.51GiB path /dev/nvme0n1
        devid    2 size 931.51GiB used 302.51GiB path /dev/nvme2n1

Label: 'X1'  uuid: 083ce778-ed85-499a-a5b6-12b79a11762c
        Total devices 2 FS bytes used 656.00KiB
        devid    1 size 3.64TiB used 2.01GiB path /dev/sdm
        devid    2 size 3.64TiB used 2.01GiB path /dev/sdn

Label: 'X2'  uuid: b105c050-574b-4070-952b-68300159c431
        Total devices 3 FS bytes used 2.90TiB
        devid    1 size 3.64TiB used 2.92TiB path /dev/mapper/sdh-crypt
        devid    2 size 3.64TiB used 2.92TiB path /dev/mapper/sdg-crypt
        devid    3 size 3.64TiB used 2.92TiB path /dev/mapper/sdb-crypt

Label: 'X3'  uuid: f2f2eeee-2c5f-4289-b597-b18000c1ae05
        Total devices 3 FS bytes used 1.92TiB
        devid    1 size 2.73TiB used 1.98TiB path /dev/mapper/sdl-crypt
        devid    2 size 2.73TiB used 1.98TiB path /dev/mapper/sdk-crypt
        devid    3 size 2.73TiB used 1.98TiB path /dev/mapper/sdj-crypt

bad tree block 26568220622848, bytenr mismatch, want=26568220622848, have=0
ERROR: failed to read block groups: Input/output error
warning, device 8 is missing
warning, device 7 is missing
warning, device 9 is missing
bad tree block 13701009637376, bytenr mismatch, want=13701009637376, have=0
ERROR: cannot read chunk root
Label: 'X4'  uuid: 48e9afff-b502-469f-b737-c773605639a0
        Total devices 9 FS bytes used 31.48TiB
        devid    1 size 16.37TiB used 16.37TiB path /dev/mapper/sdai-crypt
        devid    2 size 16.37TiB used 16.37TiB path /dev/mapper/sdaf-crypt
        devid    3 size 16.37TiB used 16.37TiB path /dev/mapper/sdag-crypt
        devid    7 size 10.91TiB used 4.29TiB path /dev/mapper/sdt-crypt
        devid    8 size 10.91TiB used 4.29TiB path /dev/mapper/sdi-crypt
        devid    9 size 10.91TiB used 4.29TiB path /dev/mapper/sda-crypt
        *** Some devices missing

Label: 'X5'  uuid: c2538874-aec5-4b0b-8230-d9b31d03473b
        Total devices 9 FS bytes used 12.11TiB
        devid    1 size 5.46TiB used 5.45TiB path /dev/mapper/sde-crypt
        devid    2 size 5.46TiB used 5.45TiB path /dev/mapper/sdd-crypt
        devid    3 size 5.46TiB used 5.45TiB path /dev/mapper/sdf-crypt
        *** Some devices missing

Je to po restartu tak mají zase jiné názvy. U X4, to tu řeším. Chybí 4,5,6. Protože nemají LUKS hlavičky a nejdou odemknout.

A ty zbylé disky mi nejdou mountnout jako degraded a píše to stejné co je i vidět zde: bad tree block 26568220622848, bytenr mismatch, want=26568220622848, have=0 ERROR: failed to read block groups: Input/output error

Od včera mi běží btrfs rescue chunk-recover -y /dev/disk/by-uuid/48e9afff-b502-469f-b737-c773605639a0 ale zatím nic nenašel.

X5 mám teď odpojené úmyslně.

A poznal jsi správně, je tam jedna USB flahska a dva malé SSD na docker. Ty nekryptované hdd jsou většinou na Chia ploty XFS. To jedno MD pole je takové překladiště kde mám starý 300GB 10000 rpm disk, jen z nostalgie. Tam jsem vyráběl ploty na Chiu. Ten brzy zemře. Dva SDD jsou v btrfs RAID0 a jedno SSD je systém.

NAME         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda            8:0    0  10,9T  0 disk
└─sda-crypt  253:3    0  10,9T  0 crypt
sdb            8:16   0   3,6T  0 disk
└─sdb-crypt  253:13   0   3,6T  0 crypt
sdc            8:32   0  10,9T  0 disk
sdd            8:48   0   5,5T  0 disk
└─sdd-crypt  253:10   0   5,5T  0 crypt
sde            8:64   0   5,5T  0 disk
└─sde-crypt  253:7    0   5,5T  0 crypt
sdf            8:80   0   5,5T  0 disk
└─sdf-crypt  253:14   0   5,5T  0 crypt
sdg            8:96   0   3,6T  0 disk
└─sdg-crypt  253:11   0   3,6T  0 crypt
sdh            8:112  0   3,6T  0 disk
└─sdh-crypt  253:6    0   3,6T  0 crypt /srv/dev-disk-by-uuid-b105c050-574b-4070-952b-68300159c431
sdi            8:128  0  10,9T  0 disk
└─sdi-crypt  253:8    0  10,9T  0 crypt
sdj            8:144  0   2,7T  0 disk
└─sdj-crypt  253:12   0   2,7T  0 crypt
sdk            8:160  0   2,7T  0 disk
└─sdk-crypt  253:9    0   2,7T  0 crypt
sdl            8:176  0   2,7T  0 disk
└─sdl-crypt  253:5    0   2,7T  0 crypt /srv/dev-disk-by-uuid-f2f2eeee-2c5f-4289-b597-b18000c1ae05
sdm            8:192  0   3,6T  0 disk  /srv/dev-disk-by-uuid-083ce778-ed85-499a-a5b6-12b79a11762c
sdn            8:208  0   3,6T  0 disk
sdo            8:224  0  10,9T  0 disk
sdp            8:240  0 931,5G  0 disk
└─md1          9:1    0   2,1T  0 raid0 /srv/dev-disk-by-uuid-d5cfecd9-41a1-4c97-a453-58a5a5064f99
sdq           65:0    0 931,5G  0 disk
└─md1          9:1    0   2,1T  0 raid0 /srv/dev-disk-by-uuid-d5cfecd9-41a1-4c97-a453-58a5a5064f99
sdr           65:16   0 279,5G  0 disk
└─md1          9:1    0   2,1T  0 raid0 /srv/dev-disk-by-uuid-d5cfecd9-41a1-4c97-a453-58a5a5064f99
sds           65:32   0   2,7T  0 disk  /srv/dev-disk-by-uuid-3c469e3d-3e09-45fe-b0eb-76cd0287938f
sdt           65:48   0  10,9T  0 disk
└─sdt-crypt  253:4    0  10,9T  0 crypt
sdu           65:64   0   2,7T  0 disk  /srv/dev-disk-by-uuid-e35e7ea6-c7b6-4a8e-9904-159ef0610737
sdv           65:80   0   2,7T  0 disk  /srv/dev-disk-by-uuid-6b32b6e6-7ad6-4e26-a497-ed2d98b211d4
sdw           65:96   0   3,6T  0 disk  /srv/dev-disk-by-uuid-ecd2369c-99b3-4647-bb78-a43e62dc6232
sdx           65:112  0   3,6T  0 disk  /srv/dev-disk-by-uuid-ba4491f0-3e1a-4314-9fc3-da6a1f324d8d
sdy           65:128  0   3,6T  0 disk  /srv/dev-disk-by-uuid-b943a5ee-755c-4b6c-8d6d-6a0854406598
sdz           65:144  0   3,6T  0 disk  /srv/dev-disk-by-uuid-1e3ccde1-51a1-46bd-809e-c9ad59086d2e
sdaa          65:160  0   5,5T  0 disk  /srv/dev-disk-by-uuid-a9c6acc6-d611-4514-9141-5ca680793136
sdab          65:176  0   3,6T  0 disk  /srv/dev-disk-by-uuid-4ec6b146-32e4-4d0f-b1b1-886d0e239711
sdac          65:192  0 232,9G  0 disk
└─sdac1       65:193  0 232,9G  0 part  /srv/dev-disk-by-uuid-6dba7e59-210e-4cd6-bde4-9df6894bf05d
sdad          65:208  0 119,2G  0 disk
└─sdad1       65:209  0 119,2G  0 part  /srv/dev-disk-by-uuid-2f4e25b2-df03-42bd-8c82-fe4dcc201344
sdaf          65:240  0  16,4T  0 disk
└─sdaf-crypt 253:1    0  16,4T  0 crypt
sdag          66:0    0  16,4T  0 disk
└─sdag-crypt 253:2    0  16,4T  0 crypt
sdah          66:16   1   7,5G  0 disk
└─sdah1       66:17   1   7,5G  0 part
sdai          66:32   0  16,4T  0 disk
└─sdai-crypt 253:15   0  16,4T  0 crypt
sdaj          66:48   0  10,9T  0 disk
nvme0n1      259:0    0 931,5G  0 disk  /srv/dev-disk-by-uuid-4d5fbc50-c661-471a-b311-ca1d8cbf9c07
nvme2n1      259:1    0 931,5G  0 disk
nvme1n1      259:2    0 465,8G  0 disk
├─nvme1n1p1  259:3    0   512M  0 part  /boot/efi
├─nvme1n1p2  259:4    0 464,3G  0 part  /
└─nvme1n1p3  259:5    0   976M  0 part  [SWAP]

SDO --> 4; SDAJ --> 5; SDC --> 6

A pro rejpaly. Jednotlivé docky neběží v ROOT ale mají samostatné uživatele s právy pouze k tomu k čemu mají mít přístup. Teda samozřejmně doufám, že jsem to nastavil správně podle nejrůznějších návodů.

[Aleš Kapica]

No. Tak to ti řeknu celkem přesně co jsi udělal.

Když jsi chystal tu druhou trojici, tak jsi převalil hlavičky těch tří kryptovaných disků, co už jsi měl v tom Btrfs. A pochopitelně sis toho nevšiml, protože ten stroj běžel a měl je už načtené v RAM. Systém ti pochopitelně nic neřekl protože pro něj disk jako disk, admin má vědět co dělá.

Kdybys to restartoval ihned, narazil bys na ten problém dřív. Jenže tys to neudělal. Přidal jsi ty disky do toho Btrfs v domnění, že jsou to ty tři nové. Ve skutečnosti jsi začal přepisovat ty cos tam už měl. No a po restartu nastal průser.

Mně takovým způsobem prokázal medvědí službu kolega, když iniciativně přidal do raid6 pole blokové zařízení exportované přes NBD a překlepl se v čísle. A projevilo se to 21. července 2012, fatální havárií stroje support. Také až po restartu. Viz stránka Peanuts.

Takže teď už jistě chápeš, proč považuji sestavení Btrfs nad kryptovanými disky za hazard. Nestalo by se ti to, kdybys to pole udělal najednou. Jenže je stejně pouze otázkou času, kdy by tě to potkalo. Dobrá rada na závěr – s tím se smiř a buď rád, že můj čas, který jsem s tím strávil nemusíš proplácet.

[RDan]

Nejsem si jistej.

První jsem měl ty 3x18TB a ty hlavičky mají. Nemají jen ty druhé 3x12TB. A přidával jsem je btrfs device add /dev/mapper/sdX-crypt. Podle mích znalostí to nemělo přepsat hlavičky.

[Want]

Však ano. O tom píšu. Ty hlavičky sis přepsal nějakým způsobem ještě předtím. Prostě jsi přepsal tu samou trojici disků. A proto máš tu druhou trojici disků prázdnou.

[Peter Golis]

Nie pred tým ale medzi pridaním nejakých zakryptovaných diskov a ich odomknutím pri jednom z následovných (re)štartov systému. OMV neprepíše lokálny disk na ktorom je odomknutý LUKS, pretože ten disk je v používaní. Pri pokuse o prepísanie používaného disku vyhlási chybu a nechá to tak, ale pri následovnom štarte ten obsluhou požadovaný prepis vykoná bez opýtania. Pred chvíľou som si to nasimuloval.

Holt, mal moc rýchle ruky a uklepol sa. Toto je jeden z dôvodov, prečo sa zmena diskového layoutu považuje za rizikovo. A z toho dôvodu je potrebné vytvoriť si zálohu (v tomto špecifickom prípade stačilo mať zálohu hlavičky LUKS).

[xxl]

Obsluha udělá něco blbě, systém sice ohlásí chybu, ale místo aby to tím skončilo, tak tu chybnou akci provede tehdy, když má první možnost???

Jestli jsem to tedy správně pochopil, tak to je killer feature systému...

[Aleš Kapica]

Jestli jsem to tedy správně pochopil, tak to je killer feature systému...

Doslova..

[Aleš Kapica]

To už je fuk. Prostě má data definitivně v riti. Marně se neříká "dvakrát měř, jednou řež".

Podle mne patří mezi nejdůležitější vlastnosti administrátora umět poslat do prdele každého, bez ohledu na postavení, kdo tlačí na pilu. Kdo to neumí, ten tuhle práci nemůže dělat, protože dříve či později udělá pod tlakem osudovou chybu.

Já než se do něčeho pustím, musím vědět co se bude dít. Takže si beru k ruce někdy i klasický papír a tužku. A kolegové mohou dosvědčit, že jsem při tom v takovém stresu, že jsem schopen vybuchnout i kvůli voloviny, pokud mne z mého soustředění někdo vyruší. Ale zatím jsem sám fatální chybu neudělal. A mé poučení ze ztráty dat v roce 2012 je takové, že řešení musí být natolik blbuvzdorné, aby ji nemohl udělat ani nikdo jiný. I když dříve či později se to stejně někomu stane, pokud k tomu nepřistoupí jako já, protože žádný systém nejede bez údržby na věky.

[Aleš Kapica]

...umět poslat do prdele každého, bez ohledu na postavení, kdo tlačí na pilu. Kdo to neumí, ten tuhle práci nemůže dělat, protože dříve či později udělá pod tlakem osudovou chybu.

Kdyby to uměl pilot, toho letadla co se vysekalo u té Katyně, skončil by maximálně bez práce. Takhle zakokrhal i s tím idiotem co ho dohnal k tomu, aby se o přistání pokusil. A jenom tím nahnal vodu na mlýn paranoidním kreténům, co za vším vidí Putina a jeho intriky.

[Peter Golis]

Podle mne patří mezi nejdůležitější vlastnosti administrátora umět poslat do prdele každého, bez ohledu na postavení, kdo tlačí na pilu.

Z hľadiska pracovného vzťahu to bolo v zákonníku práce už v minulom tisícročí. Ak niekto požadoval akciu pri ktorej je reálne riziko nevratného zlyhania (a tým pádom aj nejakých nezanedbateľných strát), tak už vtedy bola povinnosť o tom upovedomiť kompetentných. A ak to aj napriek tomu vyžadoval zadávateľ, tak nech si v rámci risk managementu zoberie na seba to riziko a podpíše zodpovednosť za to.

No ale toto je domáca hračka, a cenu tých stratených dát pozná len ich majiteľ. Či je to profesionálny fotograf (s kvantom RAW fotiek a ich verzií) alebo len hobbysta čo zálohuje internet alebo si nakrúca výletíky na nezmyselne vysoké rozlíšenie, to je vedľajšie. Vytvoril SPOF, a na to aj po preklepe prišiel. Niečo zachráni, ale dosť toho stratí.

[Aleš Kapica]

A ak to aj napriek tomu vyžadoval zadávateľ, tak nech si v rámci risk managementu zoberie na seba to riziko a podpíše zodpovednosť za to.

Nebuď směšný. Tihle vyděrači se nikdy pod nic nepodepíšou a když se ti to vysere, ještě tě v těch sražkách vyválejí. Ale velice rádi se chlubí tvými úspěchy, jako by na nich měli nějakou zásluhu.

No ale toto je domáca hračka...

Ne. To teda není. Krabici, do kterých můžeš nastrkat tolik disků neměli ani na ÚMOb Ostrava-Jih, kde běžela agenda pro 150 tisíc obyvatel, nebyla ani ve firmě pro kterou jsem dělal před lety na vedlejšák, a neměli jsme ji dlouho ani na katedře. Po pravdě řečeno – na tom výpisu jsem viděl poprvé v životě jak to vypadá v linuxu, když počet disků v systému překročí počet písmen abecedy.

[Peter Golis]

Nebuď směšný.

Klasika vo firme ktorá nepoužíva režim riadenia rizík lebo to nahradila zákonom padajúceho ho...

Krabici, do kterých můžeš nastrkat tolik disků neměli ani na

Dva plechy s dierkami na šróby, slúžiace na nacvaknutie diskov. K tomu pre istotu fukar, dobrý zdroj a dátový kábel s hniezdom. Cena je o niekoľko rádov nižšie ako rackový disk shelf na 12 hotplug diskov. Neodporúčam, ale dosť to používajú domáci zálohovači internetu.

[Aleš Kapica]

Řadič. To je to oč tu běží. Krom toho, nepatřím mezi zálohovače celého internetu. Zajímají mne jenom moje data.

[Peter Golis]

Příloha:

• dangerousDiskShelf.webp (21092 bytů)

Radič? Som bol doteraz v tom, že SAS kartu si človek kúpi za pár šušňov a k nej zoberie SAS to SATA hniezdo a vrazí to do plechovky. Na doma dobré (ak človeku nevadí ten hulk), do podniku ani za svet.

[Aleš Kapica]

No tak za páš šušňů to není, každý stroj to nesežere. Rozhodně se vyplatí investovat do novějšího stroje, než kupovat něco takového z druhé ruky. Už jsem to psal na jiném místě téhle diskuze.

[Peter Golis]

Ako som už písal, závisí od toho čo na tom diskovom poli má byť. Podobné lacné hračky sa predávali aj ako príslušenstvo pre RPi (SATA hniezdo aj s plexisklovými bočnicami na niekoľko diskov).

Firma s veľkou DB má iné nároky na výkon a spoľahlivosť ako živnostník čo preinštaluváva počítače/NB aj s vyčistením chladenia, alebo ako domáci hračička čo archivuje internet. A človek čo si archivuje spomienky alebo internet má zas iné nároky.

Že štátne zdravotníctvo alebo štátne školstvo majú silno obmedzenú kasu je tiež známa vec.

[RDan]

Nemám profi skříň. Jen jsem si vytunil starší plechárnu co jsem sehnal přes Bazoš a přídal tam pár rámečku z ALI.

https://ibb.co/sV1tjKT

Disků je tam tolik protože jsem všechno dal do RAID1c3 a všechny ostatní mají max do 6TB ale i míň, jak bylo vidět ve výpise. A taky mi tam běží těžba Chia v dockeru.

Jelikož se mi podařilo mountnout v degraded a data se sosají tak všem děkuji moc za pomoc a užitečné info.

Spoustu rad jsem si vzal srdci a budu o nich přemýšlet.

LUKS si asi z bezpečnostních důvodů nechám, ale zálohuju hlavičky.

Ale ty RAID1(c3) skupiny disků už nebudu svazovat k sobě ale budu je provozovat separátně a spojovat max přes MERGE-FS.

V září mi budou kopat domů optiku, takže když si nějaký NASík zprovozním v práci tak budu mít i rozumnou rychlost synchronizace.

Ceny HDD klesají vůči tomu jak se zvětšují naštěstí.

[Peter Golis]

Ceny HDD klesají vůči tomu jak se zvětšují naštěstí.

Potom pozor na šindlový zápis, hlavne u diskov ktoré ho utajene používajú. To sa mi tak zasekol zápis aj na 20 minút ...

[RDan]

Myslíš SMR ne?

Ano právě jsem si koupil tento hdd ST4000VN006 který se doslova jmenuje Seagate IronWolf 4TB CMR a dle datasheetu je opravdu CMR.

Ale zápis na něj padá až k 10 MB/a.

Zvažuji reklamaci.

[Peter Golis]

Áno, a asi to nevyreklamujeś lebo je to vlastnosť moderných diskov.

Akurát by som sa pozrel do dmesg či o sebe ten disk reporuje že používa (a aj aké zóny). Ak by to reportoval, tak sa s tými zónami vysporiada jadro pri práci s FS. A ak nie, tak sa to dá používať len pri občasnom prisypaní dát.

[RDan]

No to teda nechápu. Pokud je jasně napsáno že je CMR tak přece není důvod aby tomu padal takhle výkon.

Ale obávám se že to asi nebude Host-aware, tuto vlastnost mají jen profesionální řešení pokud vím. Seagate IronWolf který ani není PRO to asi nemá. Ale teda to to že je CMR jsem očekával, ušetřil bych tři stovky kdybych si koupil SMR :D

[RDan]

Tak jen pro info, důvod absence LUKS hlaviček bude možná zakopán jinde a né v zmíněné aktualizaci biosu.

Vytvořil jsem si BTRFS RAID1 a těch odepsaných discích. Předtím jsem je vymazal nějakou funkcí co vymaže začátek hdd.

BTRFS odmítl:

root@r-omv:~# mkfs.btrfs -d raid1 -m raid1 -L XY  /dev/sdi /dev/sdp
btrfs-progs v5.10.1
See http://btrfs.wiki.kernel.org for more information.

ERROR: failed to write super block for devid 2: flush error: Input/output error
failed to write new super block err -5
ERROR: unable to commit transaction: -5
ERROR: device scan failed on '/dev/sdi': Invalid argument
ERROR: device scan failed on '/dev/sdp': Invalid argument

Nicméně s parametrem -F je nakonec vytvořil s chybou ERROR: superblock magic doesn't match.

Ale pokud se snažím přečíst přes hexdump, tak tam je zase na začátku prázdno:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00010000  c2 71 81 55 00 00 00 00  00 00 00 00 00 00 00 00  |.q.U............|
00010010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00010020  96 74 10 80 70 be 4a 64  91 9f ec bd e5 42 87 11  |.t..p.Jd.....B..|
00010030  00 00 01 00 00 00 00 00  01 00 00 00 00 00 00 00  |................|
00010040  5f 42 48 52 66 53 5f 4d  05 00 00 00 00 00 00 00  |_BHRfS_M........|
00010050  00 40 d2 01 00 00 00 00  00 40 50 01 00 00 00 00  |.@.......@P.....|
00010060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00010070  00 00 00 00 d4 15 00 00  00 00 02 00 00 00 00 00  |................|
00010080  06 00 00 00 00 00 00 00  02 00 00 00 00 00 00 00  |................|
00010090  00 10 00 00 00 40 00 00  00 40 00 00 00 10 00 00  |.....@...@......|
000100a0  81 00 00 00 05 00 00 00  00 00 00 00 00 00 00 00  |................|
000100b0  00 00 00 00 00 00 00 00  00 00 00 00 41 01 00 00  |............A...|
000100c0  00 00 00 00 00 00 00 00  00 02 00 00 00 00 00 00  |................|
000100d0  00 00 00 00 00 ea 0a 00  00 00 00 80 80 00 00 00  |................|
000100e0  00 00 10 00 00 00 10 00  00 00 10 00 00 00 00 00  |................|
000100f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00010100  00 00 00 00 00 00 00 00  00 00 00 29 c9 9b 09 6c  |...........)...l|
00010110  b9 4f 2b a8 36 1a 78 fe  0f 84 37 96 74 10 80 70  |.O+.6.x...7.t..p|
00010120  be 4a 64 91 9f ec bd e5  42 87 11 58 34 00 00 00  |.Jd.....B..X4...|
00010130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

[Peter Golis]

Týdny to běželo a včera jsem restartoval kvůli aktualizaci biosu

Neaktualizoval ten BIOS aj FW pre (interný) HW RAID radič? Niekedy to resetne nastavenia radiča, a vznikne z toho problém. Také updaty zvyknú mať poznámku v pribalenom dokumente že treba zálohovať obsah diskov. Ale občas bola možnosť to prestaviť v BIOSe na pôvodné hodnoty a nabehlo to.

PS: 12 diskov doma, to si mal odložené v špajzi aby ťa to nerušilo? Veď to muselo hučať jak (ehm).

[RDan]

Nemám interní Raid řadič. Mám 16ti portovou SAS kartu a pak ještě jednu 8x s expanderem.

Na noc se většina disků uspí a skříň je na gumě pod pračku ale sto pro tiché to není :D

[Peter Golis]

Mne išlo o to, či ten radič nemal update FW a s tým spojenú zmenu nastavení (resp. reset nastavení na niečo iné). Poprípade to niekedy vyfluslo HW cache aj keď tam bola baterka na jej zachovanie. Občas sa človek dopátra či sa to dá prestaviť na pôvodné (staré) nastavenie, že by tie disky "oživil".

Ale doma by mi taký hluk z 12 rotačákov vadil aj cez deň, aj keď bývam kúsok od využívaného heliportu.

[RDan]

Připojil jsem to i na jiné porty, sata. I do jiného PC. Všude tvrdí že disk je prázdný.

[Want]

Nic proti, ale koledoval sis o to. Svěřit tolik dat tak komplikovanému řešení, kterému navíc do hloubky nerozumíš, to je koleda o průser.

[Peter Golis]

Pokiaľ je sú tie disky na inom HW prázdne (nielen prvých pár blokov), tak by som kontaktoval výrobcu ako postupovať v prípade updatu jeho FW. Update BIOSu dosky to asi neurobil.

[RDan]

Jo takhle. No na jiném pc jsem přímo na ty bloky nekoukal. Jen jsem otevřel Gparted. To ještě můžu zkusit.

[Peter Golis]

Aby neboli tie disky len poprehadzované. Domáci segment totižto robí update FW s odpojenými diskami. Firemný segment pred updatom FW skontroluje či zbehli zálohy, a v prípade potreby to jednoducho obnoví.

[RDan]

Aktualizoval jsem BIOS základní desky, předtím už jsem to tak dělal několikrát. Předtím jsem řádně ukončil systém. Nechápu jakej by to mělo mít vliv na LSI SAS kartu.

A to že disky mají pokaždé jiné /dev/sdX je přece vlastnost UDEV a ten Debian s tím počítá. Ostatní disky které vidí jako LUKS tak jsou normálně odemčené a fungují. Dokonce jsou odemčené i ty zbylé co patří k těm třem nečitelným.

[Peter Golis]

Aktualizoval jsem BIOS základní desky, předtím už jsem to tak dělal několikrát. Předtím jsem řádně ukončil systém. Nechápu jakej by to mělo mít vliv na LSI SAS kartu.

Keby to bola interná karta, tak sa jej ten FW bundle môže týkať. A boli aj prípady keď pripojený HW zle interpretoval príkaz, a vykonal niečo iné. Napríklad nejaké DVD vypaľovačky od LG zle interretovali normovaný príkaz na kalibráciu zápisu ako upload firmware, riešili to vlastnými ovládačmi (pre Windows). Vlastnil som v tej dobe zakúpenú mechaniku Teac ktorá sa bez hanby hlásila ako rebrand LG, a nebolo mi všetko jedno.

A to že disky mají pokaždé jiné /dev/sdX je přece vlastnost UDEV

To je vlastnosťou jadra OS, nie UDEV (i keď udev sa staral o hotplug a premenovanie zariadení vytvorením aliasov alebo premenovaním sieťových zariadení). Poradie detekovaných zariadení bolo závislé od toho, ako ich našiel OS. Teda v akom poradí sa roztočia a v akom poradí sa inicializujú jednotlivé radiče. Preto sa pri diskoch zvykli používať tie aliasy. V prípade LUKS to len zdetekovalo hlavičku, po zadaní hesla odomklo, a išiel ďalší krok ktorý si to mohol sám ponachádzať (LVM, BTRFS a ZFS si to našlo samé). Problém pri diskoch to robilo keď boli v OS pseudonáhodne poprehadzované disky a jeden z nich vypadol. Ak nevedela doska s tým diskom zablikať (vlastnosť serverových zostáv), tak to človek musel hľadať podľa typu a sériového čísla.

Skús si pozrieť čo ti píše o takto "premenovaných" zariadeniach následovný príkaz: ls -ld /dev/*/by*/*

Dokonce jsou odemčené i ty zbylé co patří k těm třem nečitelným.

Ak ich odomklo a mal si tam BTRFS profil B1C3 (zrkadlenie cez 3 disky), tak ti to vyskladalo celé diskové pole a problém si eliminoval.

[RDan]

Jak jsem psal nahoře prvním příspěvku. Celé pole je z 9x hdd RAID1c3. Přidával jsem je postupně, takže se navzájem zrcadlí vždy ty tři. A mě přestaly fungovat ty prostřední tři na kterých jsou data které se vzájemné zrcadlí. První trojice a poslední trojice jsou odemčené a čitelné. A až definitivně zde na fóru zjistím že nic nejde obnovit tak půjdou připojit v degradovaném režimu.

[Peter Golis]

Ale to je niečo iné ako si písal včera pred polnocou.

Ak nemáš prístup ku nejakej kópii luksHeader, tak máš smolu a niektoré dáta to neprečíta. LUKS sa totižto nešifruje zadávaným heslom. To heslo (alebo kľúč) slúži na prístup k peňaženke (wallet) ktorá obsahuje samotný kryptovací klúč. Je to kvôli tomu, aby sa vedeli pridať alebo odobrať prístupy určitým ľuďom alebo zariadeniam na odomknutie disku.

OMV nepoznám, ale je možné (ako tu už bolo spomenuté), že vytvoril LUKS aj so záložnou kópiou na disku alebo si ju niekam odpamätal. Alebo že použil jeden header (resp jednu peňaženku) na všetky disky systému alebo aspoň celej skupiny diskov patriacej jednému prípojnému bodu.

A ak nie, tak smolka. Niektoré súbory budú v kremíkovom nebi. Môže byť že to neboli najnovšie, teda v prípade ak si dal vybalansovať dáta kvôli výkonu.

PS: To už bolo rozumnejšie urobiť mirror cez dva disky a tretí mať v záložnom počítači na ktorý by si to raz za čas synchronizoval ako zálohu a mal ho inak kompletne vypnutý.

[RDan]

Nemám kopii, protože jsem netušil že je tak důležité je mít. Nemám ani kopie MBR ani GPT na jiných počítačích. Také jsem netušil že se to může samo ztratit.

Každý disk jsem přes GUI šifroval, není tam možnost jich nějak vybrat víc. Jedině že by se to nějak stalo samo.

Druhý pc je eventuální budoucnost ale to je zase dost financí.

[Peter Golis]

Ja by som skontroloval či náhodou niekoho pred rokmi nenapadlo urobiť blbuvzdornejšie. návod (len sa treba trafiť s zariadeniami), a dumpni z tých dvoch funkčných skupín či to tam nie je rovnaké.

A druhý PC? Spomínal si že si to pripojil na iný počítač, ale to mohol byt zas preklep.

[RDan]

Díky za odkaz, prozkoumám to.

Druhý PC tu mám s dualbootem Win11 a Ubuntu. Kvůli různým záchranám dat z noťasů kamarádů a podobně. Pokud bych měl z toho stavět záložní NAS tak to už by chtělo aby tam byl taky RAID1 a ECC ram atd...

[Peter Golis]

Prečo druhé NAS? Ak sa tam zmestia tie 3 disky, tak to stačí (s doplnením SW stacku BTRFS a niečo na sync súborov) a bez automatického pripájania oneskorenej repliky. Proste to raz za čas nakopneš, pripojíš a synchronizuješ aktuálny stav z NAS.

Keď sa ti znova zrúbe NAS, tak ho obnovíš z postaršej repliky na tom servisnom PC. Keď sa ti zrúbe pre zmenu servisné PC, tak ho preinštaluješ od základu a sync z NAS bude trvať dlhšie. Ak sa ti ovšem zrúbu obidva kompy (v jednej lokácii napr. z dôvodu požiaru, vytopenia alebo porúch s elektrikou), tak budeš v prdeli. Ale s oveľa menšou pravdepodobnosťou.

[RDan]

Teď jsem na disk kouknul z Ubuntu a vidí to samé, chybí 4 MiB.

[Ladik]

1. Vypada to na stejny problem jako tady (s resenim): https://unix.stackexchange.com/questions/295510/mounted-drive-disappears-and-is-no-longer-a-valid-luks-device

2. Mimochodem dalsi stejny problem OMV (bez reseni, ale mnoho informaci): https://forum.openmediavault.org/index.php?thread/28545-raid-1-mirror-with-luks-encryption-missing-after-reboot-edit-of-config-xml/&pageNo=1

3. OMV6 ma kodove jmeno Shaitan, coz je satan arabsky Ja bych mu nezveril ani bajt...

[RDan]

Díky, to prozkoumám.

Jinak OMV tvrděj že pževážně používaj funkce které má Debian sám o sobě a oni k tomu dělají jen GUI.

[Andrej]

Vypadá to, že tam jsou i další, nedávné problémy.

[Michal]

Co to zpusobilo uz asi nezjistis. Mohlo se to stat dlouho pred restartem protoze ta hlavicka je potreba jen pri mountu. Restart samotny to neudelal, spise ten update biosu. Ty softy nikdo netestuje. Vyrobce ma stovky desek s aktivni podporou, pro kazdy vyda nekolik BIOSu rocne. Pokud si myslis, ze to tam nejak zevrubne testujou (zejmena v exotickych konfiguracich), tak jsi na omylu. Doufam, ze jsi alespon ten bios jsi aktualizoval z nejakeho konkretniho duvodu. Protoze pokud "jen tak", tak si muzes nadavat jeste vic, nez uz si asi nadavas.

Beru, ze jsi nevedel, ze je dobre mit zalohovane LUKS hlavicky. Ale ze jsi nevedel, ze je dobre mit zalohovana data a ze RAID neni zaloha, tomu neverim.

[miki]

Podla vsetkeho sa ten borec stale v tom diskovom poli vrta bez toho aby presne vedel co robi. Uz len poznatok, ze dolezitych 12TB dat o ktore nechce prist ma len na jednom mieste svedci o mnohom.

[RDan]

Vím že raid není záloha. Ale zatím jsem nevykradl banku abych si nakoupil kartony bly-ray disků. Snažil jsem se zmenšit riziko třetím partiním diskem a to že je každá jiná značka. Koupil jsem si drahej zdroj a doufal jsem že nepřiletí kulovej blesk.

To že se mi záhadně ztratí LUKS hlavičky mě fakt nenapadlo ani v nejhorším snu.

[Nereknu]

Ale ty si nemusíš kupovat bluray disky. Stačí mít usb externí disk a na ten to třeba jednou týdně lifrovat a pak to fyzicky odpojit. Ideálně to nemít šifrované a když už jo, tak nějak inteligentně.

ideální dodržovat pravidlo 3-2-1 (3 kopie, 2 media, 1 mimo pracoviště).

[Nereknu]

Navíc by tě to vyšlo navíc na 200kč za usb externí box. raid1c3 má skoro stejné rizika odejití jako raid1c2 - tedy je pravděpodobnější, že ty data jsou v prdeli kvůli uživatelské chybě nebo kvůli požáru, než to, že odejdou 3 disky po sobě.

[Tim]

Presne, externi box nebo rovnou docking. Pri vyberu pozor na to jakou max kapacitu podporuji. Treba tenhle umi 16TB disky a dokonce i USB Attached SCSI protokol takze je rychlejsi nez bezne USB3. To ale bude stejne zbytecny luxus dokud tam nebudes strkat SSD, rotacni disky tu rychlost nevyuziji.

RSHTECH HDD Docking station

[Michal]

Bezneho cloveka asi jen tak nenapadne SW nebo HW chyba, ktera mu umazne kus disku. I kdyz teda zrovna u BTRFS bych teda zadnou podstatnou cast sveho tela nevsadil, ze se to nerozpadne samo o sobe. Ale to jen tak na okraj. Me takove veci napadaji pac jsem za to placeny Na druhou stranu: zivel, prepeti (ani kvalitni zdroj proti tomu vzdy neochrani), zlodej, ransomware a hlavne stara dobra lidska chyba by ho napadnout mely i v bdelem stavu, ne jen ve snu. Proto jsou v takovych pripadech a omezenem rozpoctu 2 nezavisle kopie bez RAIDu bezpecnejsi nez RAID pokud si muzes dovolit prijit o data zapsana v obdobi, nez se ty kopie syncnou.

[-]

asi ta data tak dulezita nebyla, kdyz jsou jen na jednom miste a jeste nad BTRFS

[Sherlock]

Muzem dedukovat mily Watsone. Terabajty. Zasifrovane. Dvojnasobna redudance. Tam byly ve hre emoce a ne rozum. Tak ja tipuju videa z domacich swingers party.

[Andrej]

Data, na kterých záleží, samozřejmě jsou nad Btrfs. Právě proto, že na nich záleží. To jenom někteří anonymní trollové mají předlouhé vedení.

Poznámka o jednom místě je ovšem správná; zálohování musí být fyzicky rozmístěné tak, že požáry ani povodně ani bugy v OMV6 (nebo co to bylo za systém) nezasáhly všechny repliky dat naráz.

[Heretik 《小魔神》]

No to je neštěstí! Takové neštěstí!!!

Seriózně, dovolím si předpokládat, že systém byl infikovaný, a uvedený jev je symptomatický jako zametení stop intruze.

Ještě seriózněji, na rozsáhlá domácí disková pole běžně používám geli šifrování pod ZPOOLy se ZFS filesystémem, ale dotýkat se biosu jakkoliv bych se u provozně citlivého stroje neodvážil. Každý technický zásah, i ten nejmenší, vyžaduje nejdřív důkladnou archivaci.

Použít LUKS s BTRFS by mě vůbec nenapadlo, ty považuji za nezralé a nedostatečně ověřené dlouhodobým provozem. Klíčový problém je tedy volba základní platformy pro implementaci pole, mělo to být BSD a nikoliv Linux.

Připomínám, že NFS mezi BSD a Linuxem je spolehlivější než mít přímo ZFS na Linuxu. Linux spadne často, zejména má-li GPU, zatímco ZFS/NFS na BSD běží spokojeně roky v kuse.

[Peter Golis]

Tento subjektívny názor vyzerá odborne.

Ale vedel by si odporučiť HW ktorý je vhodný na NAS, zvláda pripojenie viacerých diskov, vie šifrovať (voliteľne aj deduplikovať), má dostatočný výkon a nemá GPU?

[Tim]

Momentalne je hitem pro domaci NAS tahle deska Whisverse N5095. To "nema GPU" nejak nechapu, zrejme byla rec o externi GPU

[Peter Golis]

Nebola reč o externom GPU, bola reč o nestabilite Linuxu GPU. Vidím v tom akurát tak chabý pokus o trolling opierajúci sa o doby pred vztýčením prostredníka firme Nvidia.

Takže si počkám na vyjadrenie že ktoré NAS nemá GPU. Historicky také existovali, ale vymizli.

PS: Pri 12 diskoch by som dal radšej prednosť SAS radiču a diskovému shelfu.

[Heretik 《小魔神》]

Pokud dávám servrové pole na stroj, který má nějakou integrovanou grafiku, zásadně konfiguruji unikódovou EFI framebuffer konzoli, čímž se vyhnu jakémukoliv modesettingu v BSD jádře a i zbytečným ovladačům. To je moje technická volba, pro uložená data o jedno riziko méně.

Ale chápu a rozumím tomu, že fanatiční linuxáci něco takového považují za trolling, když i unikód v konzoli je pro ně pouhá fantazie a jsou nadšeně spokojeni třeba s tím, že peklo radeonu nevydrží běžet dva týdny v kuse.

[Peter Golis]

Ten EFI framebuffer nejde cez sériák, ide cez grafiku (GPU). Takže ešte raz a znova, ktorý NAS je v dnešnej dobe bez GPU ktoré by zhadzovalo Linux?

[Whaaaat?]

Proc geli, kdyz zfs umi sifrovani nativne?

[Max]

Jaká je specifikace toho serveru / základní desky a těch SAS řadičů?
Zdar Max

[X]

Pouzil jsi oficialni openmediavault-luksencryption plugin?

[RDan]

Ano.

[X]

Pokud jsi postupoval v souladu s konfiguracnim rozhranim OMV a nedelal jsi zadny nestandartni zasah. Navrhuji zalozit Github issue, vzhledem k tomu, ze se jedna o zavaznou chybu, ktera muze postihnout kohokoli. Zaroven dostanes fundovanejsi rady a jak to oddiagnostikovat a najit presnou pricinu.

[To zas dopadne]

Kdyz se kouknes na jejich forum tak zjistis ze to tam frci standardni free cestou - 3x te budou presvedcovat ze u nich chyba neni a delas neco spatne jen aby nemuseli nic delat. Kdyz nahodou dodas dukazy tak ti napisou ze mas poslat patch a ze se na to mozna podivaji nez to zahodi.

[..... Izak .....]

Podle me je blby napad sifrovat kazdy disk zvlast - lepsi je si udelat SW raid a zasifrovat az ten - nez kopii bloku v BTRFS mam radeji raid5/6 - pokud bych sifroval kazdy disk, asi bych si udelal LVM a nebo aspon partitions a jel to pres UUID - preci jen bordel v discich je bordel v discich a kdyz neco pridam, vidim, ze to nema part. tak je to ten novy disk - mam GPT part uplne vsude, i na SW raid - uz jen pro ten poradek - btw u GPT jde dat i label.

Nektere disky umi sifrovani samy, strasny maras, pokud nezadas sviji passphase, tak se disk nikdy nezamkne a vlastne nikdo neresi ze je sifrovany, jde vytahnout a provozovat jinde, ale pokud nekdo resetne disk FW - disk si sam vygeneruje novy klic a dik je vlastne security wiped - pro FW je ted prazdny nebo vidi nejaky bordel, kteremu nerozumi a ignoruje jej - ale to by nebyla prazna jen hlavicka, ale cely disk, presneji by nebyla prazdna, ale byl tam nejaky binarni bordel.

Jo to ze BTRFS neumi sifrovat je skoda, odladlo by kupa problemu, dlasi moznost sifrovani je jen nekterych addr. a to resi userspace, ale jak je to rychle nevim, asi nic moc - to funguje pres fuse, ze je addr. tam je bordel a ten se prepoji do addr. kde je to rozsifrovane.

Osobne se priklanim k tomu, ze admin disk prespal a nekde se spletl a tak vesele prepisoval ne jen LUKS a hlavicky, ale i data - a nebo je tam nejaka chyba, ktera ty LUKS hlavicky maze - to ze jsme se stim nikdy nesetkal neznamena, ze to neexituje, ZFS jednu dobu tak nicil bloky souboru.

btw. ZFS neni dobry FS, je to strasny smejd a pokud se poskodi, nelze jej opravit, krom toho jeho dedupliakce kdy to zere RAM je taky na h* aspon u SSD disku uz by to mohl udrzovat na nich a ne v RAM - tak jak to dela NetApp a nebo deduplikace procesem, kdy neni inline, ale jednou zaaa cas si clovek spusti proces, on to tak umi z XFS a BTRFS - btw. BTRFS umi i deaemona s databzi, kdy si hlida co se zmenilo a treba co 30 min zdeduplikuje jen nove soubory

[Max]

Absolutní nesouhlas skoro se vším. Mám z toho pocit, že jsi všechno z toho viděl z rychlíku.
Zdar Max