Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
1.0101 4.0201 7.0301 2.0102 5.0202 8.0302 3.0103 6.0203 9.0303 3x18TB 3x12TB 3x12TBSestavil 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...
Řešení dotazu:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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.
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.
11.1.2024 13:20
Max | skóre: 72
| blog: Max_Devaine
11.1.2024 19:10
Max | skóre: 72
| blog: Max_Devaine
12.1.2024 10:30
Max | skóre: 72
| blog: Max_Devaine
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.
12.1.2024 10:31
Max | skóre: 72
| blog: Max_Devaine
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.
13.1.2024 14:09
Max | skóre: 72
| blog: Max_Devaine
13.1.2024 17:26
Max | skóre: 72
| blog: Max_Devaine
13.1.2024 17:05
Max | skóre: 72
| blog: Max_Devaine
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
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.
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.
~ # 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 argumentZkusil 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.
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.
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
14.1.2024 18:38
Max | skóre: 72
| blog: Max_Devaine
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.
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.~ # 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
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"}}
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":'
# 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/loop0p1takže ty keysloty tam nejsou původně. Taky tam tvoří EXT2, já bych to měl tedy nahradit BTRFS.
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.
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č.
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á.
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 failedTakto by to mělo být ale stejně.
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 dev5Už 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é.
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 failedNic 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?
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
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).
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.
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.
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.
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:
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.
/dev/sda má velikost 5,5 TB/dev/sdb má velikost 3,6 TB/dev/sdc má velikost 3,6 TB/dev/sdd má velikost 5,5 TB/dev/sde má velikost 5,5 TB/dev/sdf je připojen na /srv/dev-disk-by-uuid-b105c050-574b-4070-952b-68300159c431 (má velikost 3,6)/dev/sdg má velikost 10,9 TB/dev/sdh má velikost 3,6 TB/dev/sdi má velikost 10,9 TB/dev/sdj má velikost 10,9 TB/dev/sdk má velikost 16,4 TB/dev/sdl ???/dev/sdm má velikost 10,9 TB/dev/sdn má velikost 2,7 TB/dev/sdo má velikost 2,7 TB/dev/sdp je připojen na /srv/dev-disk-by-uuid-f2f2eeee-2c5f-4289-b597-b18000c1ae05 (má velikost 2,7 TB)/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)/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)/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)/dev/sdt je připojen na /srv/dev-disk-by-uuid-3c469e3d-3e09-45fe-b0eb-76cd0287938f (má velikost 2,7 TB)/dev/sdu je připojen na /srv/dev-disk-by-uuid-e35e7ea6-c7b6-4a8e-9904-159ef0610737 (má velikost 2,7 TB)/dev/sdv je připojen na /srv/dev-disk-by-uuid-ba4491f0-3e1a-4314-9fc3-da6a1f324d8d (má velikost 3,6 TB)/dev/sdw je připojen na /srv/dev-disk-by-uuid-6b32b6e6-7ad6-4e26-a497-ed2d98b211d4 (má velikost 2,7 TB)/dev/sdx je připojen na /srv/dev-disk-by-uuid-ecd2369c-99b3-4647-bb78-a43e62dc6232 (má velikost 3,6 TB)/dev/sdy je připojen na /srv/dev-disk-by-uuid-b943a5ee-755c-4b6c-8d6d-6a0854406598 (má velikost 3,6)/dev/sdz je připojen na /srv/dev-disk-by-uuid-1e3ccde1-51a1-46bd-809e-c9ad59086d2e (má velikost 3,6 TB)/dev/sdaa je připojen na /srv/dev-disk-by-uuid-a9c6acc6-d611-4514-9141-5ca680793136 (má velikost 5,5 TB)/dev/sdab je připojen na /srv/dev-disk-by-uuid-4ec6b146-32e4-4d0f-b1b1-886d0e239711 (má velikost 3,6 TB)/dev/sdac má velikost 16,4 TB/dev/sdad má velikost 3,6 TB/dev/sdae má velikost 3,6 TB/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/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/dev/sdah (má velikost 16,4 TB)/dev/sdai má velikost pouhých 28,6 GB a jeden diskový oddíl, takže to tipuji na zapíchnutou USB flashku/dev/sdaj má velikost 3,6 TB/dev/sdak má velikost 3,6 TB/dev/sdal má velikost 3,6 TB/dev/sdam má velikost 3,6 TB/dev/sdan má velikost 10,9 TBA 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
/dev/nvme0n1 o velikosti 931,5G je připojený na /srv/dev-disk-by-uuid-4d5fbc50-c661-471a-b311-ca1d8cbf9c07/dev/nvme1n1 je připojen na /srv/dev-disk-by-uuid-4d5fbc50-c661-471a-b311-ca1d8cbf9c07 (má velikost 465,8G)/dev/nvme2n1 o velikosti 931,5G připojený není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.
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ů.
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.
Jestli jsem to tedy správně pochopil, tak to je killer feature systému...
Doslova.. 
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.
...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.
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í.
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.
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 naDva 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.
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í.
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 ...
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 argumentNicmé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 |................|
Týdny to běželo a včera jsem restartoval kvůli aktualizaci biosuNeaktualizoval 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).
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 UDEVTo 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.
Ja bych mu nezveril ani bajt...
Vypadá to, že tam jsou i další, nedávné problémy.
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.
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.
12.1.2024 10:34
Max | skóre: 72
| blog: Max_Devaine
- 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
24.1.2024 19:30
Max | skóre: 72
| blog: Max_Devaine
Tiskni
Sdílej:
