Portál AbcLinuxu, 6. června 2024 10:11
Asi před čtrnácti dny mne poprosil kamarád, jestli bych mu nedal k dispozici svůj archiv – šlo cca 3TB dat. A protože se mi doma válel jeden plonkovní 4TB Seagate Desktop SSHD, nakopíroval jsem data na něj a ten mu dal k dispozici. Ovšem po zkopírování cca 250GB mu ten disk velice podivným způsobem umřel. Dost mě to vyplašilo, protože další dva disky tohoto typu jsem "dočasně" použil u svého domácího úložiště – a právě ten, co mu chcípnul jsem měl připravený pro případ, že by se jeden z nich odebral do věčných lovišť. Rozhodl jsem se jich tedy urychleně, za každou cenu, zbavit. Abych mohl přejít k jádro pudla, je nutné zabrousit do historie těchto disků.
Disk, který chcípnul, byl jedním ze tří disků tohoto typu, které jsme experimentálně zakoupili na jaře 2015. Chtěl jsem je použít jako "HW podkladovou vrstvu" pod Gluster FS – do každého ze tří nodů, byl umístěn jeden disk tohoto typu. Ovšem ukázalo se (jak se můžete dočíst zde), že při práci se soubory většími než 4GB IO výkon těchto disků prudce klesal.
Neuplynulo ani půl roku a jeden z nich velice ošklivým způsobem chcípnul. Protože jsme do té doby neměli s SSHD disky žádnou reálnou zkušenost, napsal jsem tehdy o tom ostatním kolegům mail, z něhož cituji:
* Když takový disk odejde, tak stejně jako u vadného SSD - jsou všechna data v tahu * Navíc, když odejde, tak to v systému vyvolá kernel panic, který nějakým způsobem nabourá i souborové systémy, které s tím diskem nemají nic společného - včetně virtuálních - zřejmě je to proto, že se to tomu virtualizačnímu stroji pomíchá v paměti. * Ve smartu se u vadného SSHD žádné errory neobjeví - pouze nedoběhne do konce long test. Protože mám možnost srovnání s nepoškozeným diskem stejného typu, tak jen pro srovnání... Takhle vidí systém 4TB SSHD disk co je v pořádku.. 8 48 3907018584 sdd 8 49 3907017543 sdd1 Takhle vidí systém stejný typ 4TB disk co je vadný (povšimněte si počtu sektorů) 8 32 1759534936 sdc
I když byl vadný disk tehdy vyreklamován, okamžitě jsem přestal tyhle disky používat. Od té doby se nám válely asi dva roky bez užitku ve skříni.
Pak jsem zakoupil do svého domácího úložiště EZ Swap M2500 Series - 2.5" Mobile Rack (12 Bay) s cílem nahradit postupně 3,5" disky za 2,5". Jenže jsem neměl k dispozici dost volných SATA portů a kupovat řadič jen kvůli tomu, abych mohl dočasně žonglovat s daty, se mi nechtělo. Použil jsem tedy dva z těchto disků, abych mohl data sklepat a uvolnit alespoň dva SATA porty pro dva nové 2TB disky Seagate Samsung SpinPoint M9T. Od té doby tam zůstaly. Chlácholil jsem se tím, že ten stroj nejede pořád a pokud by jeden z těch disků umřel způsobem, jaký jsem již jednou zažil, tak si s tím Btrfs v režimu raid1 poradí, protože bude mít nepoškozený datový blok i jinde.
Neměl jsem však ujasněnou strategii do budoucna. Cena velkokapacitních rotačních 2,5" SATA disků je stále poměrně vysoká a k tomu abych mohl zapojit všechny sloty, jsem potřeboval řadič. Také deska stávajícího stroje (MSI 870A-G54) už je také za hranicí plánované životnosti. Nicméně alespoň v tomto směru mám jasno. Nová deska + Ryzen 5 s integrovanou grafikou + paměti, vyjde zhruba na 13,5 tisíce.
Moje dlouhodobé dilema vyřešila událost, zmíněná v perexu. Pokud chcípne deska, tak se k uloženým datům sice nedostanu, ale nepřijdu o ně. Kdežto pokud chcípnul jeden z těch 4TB disků a zbylá kapacita ostatních disků nestačila k tomu, abych ho mohl vyřadit a nahradit novým – tak by reálně hrozilo, že dřív než stihnu něco udělat, chcípne ještě jeden. A to už by hrozilo tím, že bych o nějaká data přišel. Půjčil jsem si tedy řadič, zapojil další sloty a nakoupil nové 2TB 2,5" disky, abych na ně data z rizikových SSHD disků přestěhoval.
Jako první šel ale na řadu starší 2TB 3,5" diskvSeagate Barracuda 7200.14 (AF) ST2000DM001-9YN164 , který již vykazoval ve smartu nějaké chyby a zcela reálně celé Btrfs pole zpomaloval. Během přesunu se začalo v logu, po každém přestěhovaném bloku dat, objevovat následující varování:
[148930.199536] WARNING: CPU: 0 PID: 9953 at fs/btrfs/ctree.h:1633 btrfs_update_device+0x1a8/0x1c0 [btrfs] [148930.199540] Modules linked in: snd_hrtimer snd_seq snd_seq_device edac_mce_amd kvm_amd ccp rng_core snd_hda_codec_realtek kvm snd_hda_codec_generic snd_hda_codec_hdmi ledtrig_audio serio_raw irqbypass pcspkr k10temp snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm evdev sg snd_timer snd soundcore sp5100_tco pcc_cpufreq acpi_cpufreq nfsd parport_pc ppdev lp auth_rpcgss nfs_acl lockd grace parport sunrpc ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod ohci_pci radeon ata_generic psmouse i2c_algo_bit xhci_pci ttm xhci_hcd pata_jmicron drm_kms_helper i2c_piix4 ehci_pci ohci_hcd ehci_hcd r8169 realtek libphy usbcore ahci libahci sata_mv usb_common libata scsi_mod drm button [148930.199611] CPU: 0 PID: 9953 Comm: btrfs Tainted: G W 5.0.0-trunk-amd64 #1 Debian 5.0.2-1~exp1 [148930.199614] Hardware name: MSI MS-7599/870A-G54 (MS-7599), BIOS V17.17 01/13/2012 [148930.199686] RIP: 0010:btrfs_update_device+0x1a8/0x1c0 [btrfs] [148930.199691] Code: 3d ff ff 4c 89 f7 45 31 c0 ba 10 00 00 00 48 8b 8b a0 00 00 00 4c 89 e6 e8 85 3d ff ff 4c 89 f7 e8 7d 1f fd ff e9 dd fe ff ff <0f> 0b eb c2 41 bd f4 ff ff ff e9 d6 fe ff ff e8 34 fd bb f0 0f 1f [148930.199694] RSP: 0018:ffffa6c7810a7b08 EFLAGS: 00010206 [148930.199698] RAX: 0000000000000fff RBX: ffff91a5da51d000 RCX: 000003a3816d1e00 [148930.199700] RDX: 0000000000001000 RSI: 0000000000003efa RDI: ffff91a45b5673b0 [148930.199703] RBP: ffff91a4c338ab60 R08: ffffa6c7810a7ab8 R09: ffffa6c7810a7ac0 [148930.199705] R10: 0000000000003000 R11: 0000000000000003 R12: 0000000000003eda [148930.199707] R13: 0000000000000000 R14: ffff91a45b5673b0 R15: ffff91a4c338ab60 [148930.199711] FS: 00007f5c8d5bf8c0(0000) GS:ffff91a5e7600000(0000) knlGS:0000000000000000 [148930.199714] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [148930.199717] CR2: 00007fb8ce1d7930 CR3: 00000001aeb2c000 CR4: 00000000000006f0 [148930.199719] Call Trace: [148930.199796] btrfs_remove_chunk+0x29e/0x710 [btrfs] [148930.199869] btrfs_relocate_chunk+0x7c/0xa0 [btrfs] [148930.199938] btrfs_shrink_device+0x1db/0x570 [btrfs] [148930.200009] ? btrfs_find_device_by_devspec+0x70/0x1a0 [btrfs] [148930.200078] btrfs_rm_device+0x171/0x570 [btrfs] [148930.200147] ? btrfs_ioctl+0x1daf/0x2da0 [btrfs] [148930.200155] ? __check_object_size+0x15d/0x189 [148930.200224] btrfs_ioctl+0x2a92/0x2da0 [btrfs] [148930.200232] ? strncpy_from_user+0x4f/0x1b0 [148930.200238] ? _copy_to_user+0x26/0x30 [148930.200243] ? cp_new_stat+0x150/0x180 [148930.200250] ? do_vfs_ioctl+0xa4/0x630 [148930.200255] do_vfs_ioctl+0xa4/0x630 [148930.200260] ? __do_sys_newstat+0x48/0x70 [148930.200266] ksys_ioctl+0x60/0x90 [148930.200272] __x64_sys_ioctl+0x16/0x20 [148930.200277] do_syscall_64+0x53/0x100 [148930.200283] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [148930.200288] RIP: 0033:0x7f5c8d6b2427 [148930.200292] Code: 00 00 90 48 8b 05 69 aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 aa 0c 00 f7 d8 64 89 01 48 [148930.200295] RSP: 002b:00007ffeaf316078 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [148930.200298] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5c8d6b2427 [148930.200301] RDX: 00007ffeaf317098 RSI: 000000005000943a RDI: 0000000000000003 [148930.200303] RBP: 0000000000000001 R08: 0000000000000400 R09: 0000000000000078 [148930.200305] R10: fffffffffffffa4a R11: 0000000000000206 R12: 00007ffeaf318218 [148930.200307] R13: 0000000000000000 R14: 0000000000000003 R15: 0000000000000003 [148930.200313] ---[ end trace d07b0193aa2b8913 ]---
Používám Btrfs již dlouho, takže vím jak vypadají hlášky, které signalizují problém. Tohle varování pouze signalizuje, že se nepodařilo po přesunu bloků aktualizovat hodnotu pro nějaké info. Takže jsem to ignoroval. Ale nebudu zastírat, že mi stále vrtá hlavou co za tím vlastně vězí. Pak jsem vyhodil první z těch 4TB SSHD. A pořád tahle hláška. Nedalo mi to a začal jsem pátrat ve zdrojáku jádra a v jeho historii změn, jestli někdo neřešil něco podobného. Ale nic kloudného jsem nenašel. A když jsem začal stěhovat data i z toho druhého SSHD disku, zase to upozornění.
Až dnes ráno, jsem natrefil na zprávu, u které mou pozorost upoutal příkaz:
btrfs inspect-internal dump-super /path/to/btrfs/device
Ze zvědavosti, jsem ho zkusil aplikovat nejdřív na diskový oddíl 4TB disku, ze kterého jsem data čerstvě odstěhoval:
stroj :~# btrfs inspect-internal dump-super /dev/sdi1 superblock: bytenr=65536, device=/dev/sdi1 --------------------------------------------------------- ERROR: bad magic on superblock on /dev/sdi1 at 65536
Jelikož jde o příkaz, který není destruktivní (vypisuje pouze informace o superbloku), poštval jsem ho i na diskový oddíl 4TB disku, který jsem zrovna stěhoval pryč:
stroj :~# btrfs inspect-internal dump-super /dev/sdj1
superblock: bytenr=65536, device=/dev/sdj1
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0x8c13b15f [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 10000000-0000-0000-0000-000000000000
metadata_uuid 10000000-0000-0000-0000-000000000000
label main
generation 463137
root 16300501598208
sys_array_size 258
chunk_root_generation 463136
root_level 1
chunk_root 6505365504
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 22004366888960
bytes_used 6702494769152
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 10
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x161
( MIXED_BACKREF |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA )
cache_generation 463137
uuid_tree_generation 463137
dev_item.uuid 9689301d-abf7-41ab-86fb-72c458eb09e2
dev_item.fsid 10000000-0000-0000-0000-000000000000 [match]
dev_item.type 0
dev_item.total_bytes 4000785964544
dev_item.bytes_used 3132104900608
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 3
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0
A pak jsem zkusil tenhle příkaz zavolat ne na diskový oddíl, ale rovnou na zařízení jako takové. A ejhle!
stroj :~# btrfs inspect-internal dump-super /dev/sdj
superblock: bytenr=65536, device=/dev/sdj
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0x1de26591 [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 845aeed6-5caa-463b-aeb3-234647e1c791
metadata_uuid 845aeed6-5caa-463b-aeb3-234647e1c791
label backup
generation 1010
root 837419008
sys_array_size 129
chunk_root_generation 1006
root_level 0
chunk_root 20987904
chunk_root_level 0
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 4000787030016
bytes_used 393216
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x161
( MIXED_BACKREF |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA )
cache_generation 1010
uuid_tree_generation 1010
dev_item.uuid 87bc4668-6acd-4873-ad19-1dfa636d1301
dev_item.fsid 845aeed6-5caa-463b-aeb3-234647e1c791 [match]
dev_item.type 0
dev_item.total_bytes 4000787030016
dev_item.bytes_used 839758381056
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0
Ukázalo se, že na tom disku už v minulosti bylo Btrfs. Ovšem nikoliv nad logickým oddílem, nýbrž nad celým diskem. A stejně tak tomu bylo i u toho druhého 4TB disku. Obvykle obsah celého disku před novým použitím přepisuji nulami, ovšem v tomto případě jsem to neudělal, protože jsem nechtěl u těch hybridních disků zbytečně opotřebovávat buňky interního ssd.
Překontroloval jsem i ostatní disky a u těch jsem nic podobného nenašel, takže jsem si myslel že příčinou toho varování, které se objevovalo v logu bylo právě tohle, jelikož velikost Btrfs z reliktního záznamu (total_bytes=4000787030016) neodpovídá aktuální velikosti pole (total_bytes=22004366888960)
Po přesunu dat z velkých 4TB disků a onoho vadného následovala operace. Vykuchal jsem koš s těmi dvěmi 4TB disky a dva boxy se dvěma 2TB 3,5" disky. Věděl jsem, že jeden z nich je ten vadný. A ten další bylo nutné vykuchat abych mohl zapojit všechny sloty tom boxu na 2,5" disky.
Po úspěšné operaci, jsem nahodil systém, zapíchnul přes externí USB ten disk který bylo nutné rovněž vyoperovat. Vrazil jsem do boxu zbylé 2x2TB ve 2,5", přidal je do Btrfs pole a odstartoval vyhození diskového oddílu z disku připojeného přes USB adaptér z pole. A opět ta hláška. Takže nevím.
Asi za 14 hodin tahle operace úspěšně skončila. Spustil jsem scrub a příjemně mne překvapilo, jak relativně svižně proběhla. 12,2TB se překontrolovalo cca za 4,5 hodiny.
Jednoduše proto, že na nich nic jiného než data být nemělo. Diskové oddíly dávají smysl v okamžiku, pokud potřebujete umístit na blokové zařízení zavaděč, abyste z něj mohli nabootovat. Pro logický oddíl na 4TB discích by navíc bylo nutné GPT. To by ovšem znamenalo další modul do jádra zavaděče GRUB2, aby si mohl sestavit pole aby z něj pak mohl nabootovat.
Ano, ale musíte použít na disku logické oddíly a mít vyhrazené místo pro zavaděč. U MS-DOS tabulky se zavaděč cpe do MBR, jenže MS-DOS tabulka má svůj limit na hranici 2TB, takže pokud kombinujete větší disky, je lepší použít GPT. Pokud plánujete, že budete používat pouze disky o velikost 2TB (jako já), vystačíte si s MS-DOS
Důvodů by se našlo hned několik, ale tím hlavním je pro mne cena. Ta se v současné době pohybuje u rotačního disku cca 1–1,5 tis./TB a stoupá víceméně lineárně až do kapacity 10TB. Kdežto u SSD disků začíná cca na 4 tis./TB a stoupá exponenciálně na aktuálně dostupné maximum 4TB. Takže když mi chcípne disk 1x2TB, tak to znamená akutně vysolit cca 2 litry. U rotačního 4TB disku by to byl víc než dvojnásobek. A za cenu takhle obludně velkého SSD disku bych koupil celou sadu nových rotačních disků o stejné kapacitě. Koupí většího rotačního disku bych sice získal o něco větší kapacitu. Ale na co? A u menších disků nepotřebuji udržovat velkou rezervu. Stačí jen tolik volného místa, aby se měly kam přesunout data z jednoho chcíplého disku. Čím více menších disků, tím víc jich může časem pochcípat aniž by to muselo skončit ztrátou dat.
Nekoupil jsem naráz disky do všech slotů proto, aby mi neskončila záruka u všech disků najednou. A časem, jestli se ceny velkokapacitních SSD disků dostanou na nějakou rozumnou hladinu, je možná začnu nahrazovat jimi.
Dalším je kapacita. V současné době mám celkovou kapacitu 18.19TiB, ze které mám reálně obsazeno 12.19TiB. A to nemám plně obsazeny 2TB disky všechny sloty.
Tiskni
Sdílej:
Ale na druhou stranu, kdyz nekoho nerozhodi stacktrace v logu pri kopirovani dat...Asi tak. Absolutně nepochopim, jak může někdo neironicky / na svoje reálný data používat filesystem, který vykazuje takovouhle nestabilitu a asi zřejmě špatnou testovanost. No ale můj problém to není a kdo chce kam, pomožme mu tam... Nicméně zápisek je pro mě přínosem v tom, že je fajn vědět, že btrfs je stále ještě v takovémhle stavu, takže díky za to...
Btrfs tehdy snad ani neexistoval.Mluvíš z hladu. Viz níže. Jinak "warning" není chyba. Pokud tuhle nuanci nechápeš, nechápu pro změnu já, co děláš v tomhle oboru.
Tam error znamena ztratu datAno, jsou souborové systémy u kterých to platí beze zbytku a pokud je Btrfs v single mode, tak rovněž. Jenomže chyba, která vede ke ztrátě dat obvykle s warningem vůbec nesouvisí. Warning je warning. Nic víc, nic míň.
Warning je warning. Nic víc, nic míň.To není pravda; není warning jako warning. Ta hláška v dmesg a ten trace je AFAIK následek makra
14.6.2019 14:32
WARN_ON(). Čiliže to je něco jako jemnější varianta assertu, kdy něco je špatně, ale není to tak hrozný, aby kvůli tomu musel nastal panic a vzít s sebou celý systém. Nicméně slouží to na verifikaci invariantů (minimálně takový je účel), proto to taky bleje stack trace a další informace, aby se to dalo debugovat. Pokud btrfs narzí na chybu, měl by ji detekovat a nějakým vhodným způsobem sdělit uživateli. Pokud to v kódu naráží na WARN_ON() a ty musíš procházet zdrojáky jádra nebo někde jinde podrobně zkoumat, co se děje, tak je IMO něco špatně.
Souhlasim s tebou, že ten warning trace nemusí nutně být a asi není symptomem nějakého iminentního fatálního selhání, nicméně z mého pohledu ten trace i to popisováné chování a jak jsi zjišťoval, co je teda vlastně špatně, ukazuje na špatnou kvalitu toho kódu a/nebo nedostatečné testování.
Diskove oddily davaji smysl vzdycky, protoze to jak funguji veci bez diskovych oddilu nikdo netestuje.To je pravda. A nejen v případě oddílů, ale i všech voleb filesystému obecně. Pokud něco není buď default nebo popsáno jako doporučená konfigurace pro nějaký konrétní typ nasazení, není moc pravděpodobné, že by to někdo před vámi nějak vážně zkoušel, natož testoval. Nicméně použití btrfs na dedikovaném blokovém zařízení bez oddílů není ten případ, protože btrfs v sobě zahrnuje jak volume management tak filesystém. Na druhou stranu existuje několik důvodů proč dávat brfs na oddíl: pokud chci mít na disku oddíl s jiným filesystémem (např. kvůli bootu nebo swapu), případně pokud chci btrfs šifrovat (pak se musí dát na LUKS volume). Pokud chápu zápisek dobře, tak chyba byla naopak v tom, že se btrfs na dedikovaném zařízení dal na oddíl místo na celý disk.
14.6.2019 15:48
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
15.6.2019 16:16
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
17.6.2019 08:55
Max | skóre: 72
| blog: Max_Devaine
17.6.2019 09:09
Max | skóre: 72
| blog: Max_Devaine
15.6.2019 06:08
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
15.6.2019 21:13
paul2no | skóre: 16
| blog: Paulovo doupě
| Praha
17.6.2019 08:43
Max | skóre: 72
| blog: Max_Devaine
512e (emulated) 512n (native) 4Kn (4096 native)Zdar Max
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
14.6.2019 22:40