Turris 1.1 - btrfs: bad tree block

Ahoj,
nebudu tu psát, co si o btrfs myslím (nic pěkného to není), ale potřeboval bych poradit.

Dnes ráno mi najednou, z ničeho nic přestal fungovat internet. Respektive, internet šel, nejela DNS. Tak jsem router restartoval. Vše naběhlo a vypadalo to OK. Nicméně odpoledne jsem zjistil, že mi nějak nejede homeassistant v LXC. V logu byla hláška: “BTRFS info (device mmcblk0p2): forced readonly”

Chvíli jsem se snažil o remount do RW, ale nešlo to. Další restart, který nic nevyřešil, spíše zhoršil. Zase nenajela DNS. V logu pak bylo:

[    9.638093] BTRFS info (device mmcblk0p2): disk space caching is enabled
[    9.645041] mount_root: loading kmods from internal overlay
[    9.807655] BTRFS error (device mmcblk0p2): bad tree block start 4611686018427387904 2611593216
[    9.816397] BTRFS error (device mmcblk0p2): bad tree block start 0 2611609600
[    9.824686] BTRFS error (device mmcblk0p2): bad tree block start 4611686018427387904 2611593216
[    9.833421] BTRFS: Transaction aborted (error -5)
[    9.833478] ------------[ cut here ]------------
[    9.838092] WARNING: at fs/btrfs/extent-tree.c:6594
[    9.842965] Modules linked in: usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_hcd uhci_hcd ahci libahci libata ehci_fsl ehci_platform ehci_hcd sd_mod scsi_mod fsl_mph_dr_of xfs libcrc32c reiserfs jfs f2fs ext4 jbd2 mbcache exfat button_hotplug input_core usbcore usb_common mii aead crypto_null
[    9.869321] CPU: 0 PID: 1005 Comm: btrfs-cleaner Not tainted 4.4.106-56ef06674a2579d8488bcbf4fe98e926-3 #1
[    9.878978] task: deb7d140 ti: deaf6000 task.ti: deaf6000
[    9.884374] NIP: c01c5500 LR: c01c5500 CTR: 00000000
[    9.889336] REGS: deaf7b40 TRAP: 0700   Not tainted  (4.4.106-56ef06674a2579d8488bcbf4fe98e926-3)
[    9.898208] MSR: 00029000 <CE,EE,ME>  CR: 28024042  XER: 00000000
[    9.904314]
[    9.904314] GPR00: c01c5500 deaf7bf0 deb7d140 00000025 00029000 00000000 00000035 c064c1bc
[    9.904314] GPR08: 00000001 c0624794 c0624794 0000018f 42024044 00000000 00000000 deac3000
[    9.904314] GPR16: 00000001 00000000 00005180 253a1000 00000000 da534068 de90b800 da58faf0
[    9.904314] GPR24: 00000000 fffffffb 00000000 00000000 00000000 00000000 00000000 c04f2acc
[    9.934052] NIP [c01c5500] __btrfs_free_extent+0x490/0xfe8
[    9.939537] LR [c01c5500] __btrfs_free_extent+0x490/0xfe8
[    9.944931] Call Trace:
[    9.947372] [deaf7bf0] [c01c5500] __btrfs_free_extent+0x490/0xfe8 (unreliable)
[    9.954604] [deaf7ce0] [c01cadb4] __btrfs_run_delayed_refs.constprop.33+0x994/0x111c
[    9.962350] [deaf7dc0] [c01cdb30] btrfs_run_delayed_refs+0x94/0x278
[    9.968620] [deaf7e10] [c01e5834] btrfs_should_end_transaction+0x6c/0x90
[    9.975323] [deaf7e20] [c01cbda4] btrfs_drop_snapshot+0x4d8/0x890
[    9.981419] [deaf7eb0] [c01e6f4c] btrfs_clean_one_deleted_snapshot+0xd0/0xec
[    9.988474] [deaf7ed0] [c01dc18c] cleaner_kthread+0x16c/0x1a8
[    9.994224] [deaf7ef0] [c004551c] kthread+0xe0/0xe4
[    9.999105] [deaf7f40] [c000daf0] ret_from_kernel_thread+0x5c/0x64
[   10.005285] Instruction dump:
[   10.008248] 7d005028 7d074b78 7ce0512d 40a2fff4 7c0004ac 710a0004 40a2001c 3c60c059
[   10.016008] 7f24cb78 3863fd1c 4cc63182 4830fdc5 <0fe00000> 7ea3ab78 7ec4b378 7fe5fb78
[   10.023943] ---[ end trace 36ddfe107eb57d98 ]---
[   10.028602] BTRFS: error (device mmcblk0p2) in __btrfs_free_extent:6594: errno=-5 IO failure
[   10.037060] BTRFS info (device mmcblk0p2): forced readonly
[   10.042562] BTRFS: error (device mmcblk0p2) in btrfs_run_delayed_refs:2930: errno=-5 IO failure

Což mne nepotěšilo. SD kartu jsem vytáhl, takže aktuálně zase jedu na ubifs.

Takže dotazy - dá se btrfs opravit? Podle mně to bude spíše chyba btfrs,
A pokud ne a budu muset kartu naformátovat a znova přemigrovat na btrfs, jaká je šance, že se mi to stane znova? Protože mně to docela nasralo, chtěl jsem dnes dělat něco úplně jiného, než se hrabat v turrisu :frowning:

Update:
teď kartu zkouším na NB a prý tam je nějaký nečitelný sektor. Přitom kartu jsem koupil dle doporučení tady - Transcend Premium 400x 32GB.

[    9.975323] [deaf7e20] [c01cbda4] btrfs_drop_snapshot+0x4d8/0x890
[    9.981419] [deaf7eb0] [c01e6f4c] btrfs_clean_one_deleted_snapshot+0xd0/0xec
[    9.988474] [deaf7ed0] [c01dc18c] cleaner_kthread+0x16c/0x1a8
[    9.994224] [deaf7ef0] [c004551c] kthread+0xe0/0xe4
[    9.999105] [deaf7f40] [c000daf0] ret_from_kernel_thread+0x5c/0x64
[   10.005285] Instruction dump:
[   10.008248] 7d005028 7d074b78 7ce0512d 40a2fff4 7c0004ac 710a0004 40a2001c 3c60c059
[   10.016008] 7f24cb78 3863fd1c 4cc63182 4830fdc5 <0fe00000> 7ea3ab78 7ec4b378 7fe5fb78
[   10.023943] ---[ end trace 36ddfe107eb57d98 ]---
[   10.028602] BTRFS: error (device mmcblk0p2) in __btrfs_free_extent:6594: errno=-5 IO failure
[   10.037060] BTRFS info (device mmcblk0p2): forced readonly
[   10.042562] BTRFS: error (device mmcblk0p2) in btrfs_run_delayed_refs:2930: errno=-5 IO failure

Co na té kartě provozujete? Většinou tyto chyby btrfs znamenají výpadek bloku a tedy postupný odchod karty do křemíkového nebe (samozřejmě, že se také může jednat o chyby v btrfs, ale ty většinou nastávají při updatu mezi verzemi jádra). Občas se problém dá opravit z počítače, ale většinou to je na kontrolu karty a reformat.

Obecně moje zkušenost s btrfs je, že samo o sobě problémy nezpůsobuje. Spíše je nevhodně hlásí. Na rotačních discích se automaticky vytváří záloha indexů a tak pokud dojde k poškození tak se potichu opraví. Na ssd je toto vypnuté a tak pokud dojde k poškození tak btrfs zahlásí chybu a podle toho o jaký sektor se jedná tak buďto odmítne mount read-write než dojde k ruční opravě, nebo neumožní čtení některých souborů. Index je ale možné zpětně sestavit pomocí programu btrfs, ale jedná se o dlouhý proces s nejistým výsledkem a tak se neprovádí automaticky. Doporučuji si ověřit stav karty, jestli náhodou už neodchází a případně se zamyslet nad tím co na routeru provozujete tak náročného na zápisy, že k této chybě došlo. Samozřejmě další možnost je náhodné poškození zapsaných dat a to se prostě stává (sd karty jsou tomu náchylnější než interní disky a flash paměti na desce).

No moc toho není. LXC kontejner s debianem mám na HDD připojeném přes USB3. Na kartě jsem měl akorát spuštěné mosquitto (mqtt server) pro BigClown. Přes něj komunikoval BigClown USB dongle a homeassistant v tom kontejneru. Mimo to jsem tam měl spuštěné OpenVPN a Transmission (úložiště opět na externím HDD). Takže netuším, co mohlo tu kartu po pouhých několika měsících takhle zničit.

Jak jsem psal, mohlo se jednat o náhodné poškození dat (to nemá nic společného se softwarem ale s hardware a jak jsem psal, sdkarty jsou na to náchylnější). A nebo jste měl štěstí na špatný kousek, nevím kolik řádově u sd karet, ale úložiště prostě v prvních několika měsících odcházejí na skryté výrobní vady, to je známá věc se kterou se třeba v data centrech počítá ve velkém. Ověřte, že se skutečně jedná a výpadek bloku (třeba pomocí příkazu badblocks) a případně kartu reklamujte.

OK. Zkouším badblock. Příkaz “brtfs check” mi vypsal hromadu chyb. Karta je asi v háji (ale poslední snapshot jsem bez problémů překopíroval do zálohy).

Asi budu muset řešit reklamaci :frowning:
Prej “Premium”…

No tak badblocks nenašel žádný vadný sektor. Nějaký nápad?

worker / # badblocks /dev/sdb
worker / # 

A výstup btrfs check

worker / # btrfs check /dev/sdb2
Checking filesystem on /dev/sdb2
UUID: fa60b801-93e0-4d40-849f-c0aa6930dc92
checking extents
checksum verify failed on 2611593216 found 24677A03 wanted 00000000
checksum verify failed on 2611593216 found 24677A03 wanted 00000000
bytenr mismatch, want=2611593216, have=4611686018427387904
checksum verify failed on 2611609600 found DD3C5953 wanted 00000000
checksum verify failed on 2611609600 found DD3C5953 wanted 00000000
bytenr mismatch, want=2611609600, have=0
checksum verify failed on 2611527680 found 1EDDAD8A wanted 0503BD31
checksum verify failed on 2611527680 found 1EDDAD8A wanted 0503BD31
bytenr mismatch, want=2611527680, have=13647719385636920098
...
ref mismatch on [624586752 4096] extent item 0, found 16
Backref 624586752 root 257 owner 20869 offset 0 num_refs 0 not found in extent tree
Incorrect local backref count on 624586752 root 257 owner 20869 offset 0 found 1 wanted 0 back 0x55f9dbd7f9b0
Backref 624586752 root 281 owner 20869 offset 0 num_refs 0 not found in extent tree
Incorrect local backref count on 624586752 root 281 owner 20869 offset 0 found 1 wanted 0 back 0x55f9d9d65bc0
Backref 624586752 root 282 owner 20869 offset 0 num_refs 0 not found in extent tree
Incorrect local backref count on 624586752 root 282 owner 20869 offset 0 found 1 wanted 0 back 0x55f9d9d64040
Backref 624586752 root 283 owner 20869 offset 0 num_refs 0 not found in extent tree
Incorrect local backref count on 624586752 root 283 owner 20869 offset 0 found 1 wanted 0 back 0x55f9da2569c0
Backref 624586752 root 284 owner 20869 offset 0 num_refs 0 not found in extent tree
Incorrect local backref count on 624586752 root 284 owner 20869 offset 0 found 1 wanted 0 back 0x55f9d9db4ea0
Backref 624586752 root 285 owner 20869 offset 0 num_refs 0 not found in extent tree
Incorrect local backref count on 624586752 root 285 owner 20869 offset 0 found 1 wanted 0 back 0x55f9da9177c0
Backref 624586752 root 286 owner 20869 offset 0 num_refs 0 not found in extent tree
...
backpointer mismatch on [624902144 12288]
ref mismatch on [650080256 28672] extent item 16, found 15
checksum verify failed on 2611560448 found 99173911 wanted 00010000
checksum verify failed on 2611560448 found 99173911 wanted 00010000
bytenr mismatch, want=2611560448, have=0
Incorrect local backref count on 650080256 root 287 owner 22623 offset 0 found 0 wanted 1 back 0x55f9dba33600
Backref disk bytenr does not match extent record, bytenr=650080256, ref bytenr=47287796087401060
backpointer mismatch on [650080256 28672]
ref mismatch on [650158080 4096] extent item 16, found 15
...
bytenr mismatch, want=2611642368, have=0
Incorrect local backref count on 1448075264 root 293 owner 46509 offset 4096 found 0 wanted 1 back 0x55f9da8d5ae0
Backref disk bytenr does not match extent record, bytenr=1448075264, ref bytenr=12105675798373966688
backpointer mismatch on [1448075264 4096]
owner ref check failed [2611511296 16384]
owner ref check failed [2611527680 16384]
owner ref check failed [2611544064 16384]
owner ref check failed [2611560448 16384]
owner ref check failed [2611576832 16384]
owner ref check failed [2611593216 16384]
owner ref check failed [2611609600 16384]
owner ref check failed [2611625984 16384]
owner ref check failed [2611642368 16384]
owner ref check failed [2611658752 16384]
owner ref check failed [2611675136 16384]
owner ref check failed [2611691520 16384]
owner ref check failed [2611707904 16384]
owner ref check failed [2611724288 16384]
owner ref check failed [2611740672 16384]
owner ref check failed [2611757056 16384]
owner ref check failed [2611838976 16384]
owner ref check failed [2611855360 16384]
owner ref check failed [2611871744 16384]
owner ref check failed [2611888128 16384]
owner ref check failed [2611904512 16384]
owner ref check failed [2611920896 16384]
owner ref check failed [2611937280 16384]
owner ref check failed [2611953664 16384]
owner ref check failed [2611970048 16384]
owner ref check failed [2611986432 16384]
checksum verify failed on 2611593216 found 24677A03 wanted 00000000
checksum verify failed on 2611593216 found 24677A03 wanted 00000000
bytenr mismatch, want=2611593216, have=4611686018427387904
ERROR: failed to repair root items: Input/output error

Pokud budete sd kartu formátovat, tak můžete ještě zkusit otestovat sd kartu i na zápis, protože jinak badblocks v read-only módu toho moc nenajde. Obecně pokud je chybný blok tak u sd karet se většinou čte jako nějaký bordel namísto toho aby čtení selhalo a to kvůli tomu, že u sd karet není sektor nijak kontrolován. Test čtením tak v podstatě otestuje jen jestli je v pořádku elektronika sd karty, ne jestli skutečně není některý z bloků poškozený. Pokud se do něho pokusíte zapsat a výsledek se nezapíše tak teprve pak zjistíte, že karta je poškozená. Tedy je nutné udělat test takto:

# badblocks -s -w /dev/sdb

Jinak, jak jsem již psal, může být nepříjemná náhodná chyba. Na sd kartách nic překvapivého.

Pustil jsem nedestruktivní write test. Je před půlkou a zatím žádná chyba. Přitom výstup z btrfs check je děsivý.

worker /etc/portage # badblocks -svn /dev/sdb
Hledají se špatné bloky v nedestruktivním režimu čtení i zápis
Od bloku 0 do 30981119
Hledají se špatné bloky (nedestruktivní test čtení i zápisu)
Zkouším s náhodným vzorkem:  41.54 % hotovo, 53:45 uplynulo. (0/0/0 chyb)

Btrfs check kontroluje stav souborového systému, ne stav úložiště. Data v úložišti mohou být náhodně poškozena a tím se může poškodit souborový systém ale náhodné změny v buňkách nemají vliv na funkci úložiště. Jak jsem psal, vidím to buďto na náhodnou chybu v indexu (většinou způsobené zářením), nebo na chybu na sd kartě. Až doběhne badblocks s testem na zápis (nikdy jsem nedestruktivní mód nepoužil takže nevím jestli něco najde ale dokumentace píše, že dělá zápisy tak by měl dělat zápisy) tak budete vědět která z těch dvou variant vypadne. Samozřejmě je zde stále možnost softwarové chyby, ale myslím si, že pokud nepředcházel problémům nějaký update tak to považuji za méně pravděpodobné než dvě předchozí varianty (pokud jste na router sám třeba něco nekopíroval velkého nebo tak).

87%, zatím stále bez chyby. Žádný update tam nebyl, nic jsem tam nekopíroval, jen ráno prostě vypadla DNS, tak jsem udělal restart, naběhlo to a jeli jsme pryč. Až po návratu jsem začal řešit nefunkční HomeAssistant. Dle logu se to do ro režimu přeplo v 11:05 - to jsme už nebyli doma.

Jan  7 08:15:45 localhost kernel: [   75.534150] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.
Jan  7 11:05:07 localhost kernel: [10237.642084] ------------[ cut here ]------------
Jan  7 11:05:07 localhost kernel: [10237.642089] WARNING: at fs/btrfs/extent-tree.c:6594
Jan  7 11:05:07 localhost kernel: [10237.642093] Modules linked in: option iptable_nat ip6table_nat ath9k usb_wwan rndis_host qmi_wwan pppoe nf_nat_pptp nf_nat_ipv6 nf_nat_ipv4 nf_nat_amanda nf_conntrack_pptp nf_conntrack_ipv6 nf_conntrack_ipv4 nf_conntrack_amanda ipt_REJECT ipt_MASQUERADE ftdi_sio ebtable_nat ebtable_filter ebtable_broute cdc_ether ath9k_common xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_socket xt_recent xt_nfacct xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TPROXY xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY usbserial usbnet ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda ts_kmp ts_fsm ts_bm pppox ppp_mppe ppp_async nfnetlink_acct nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_nat_h323 nf_nat_ftp nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack_broadcast lm90 iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables hwmon gpio_keys ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 crc_ccitt cdc_wdm cdc_acm ath9k_hw fuse sch_teql sch_tbf sch_sfq sch_red sch_prio sch_pie sch_netem sch_htb sch_gred sch_fq sch_dsmark sch_codel em_text em_nbyte em_meta em_cmp cls_basic act_vlan act_police act_pedit act_nat act_ipt act_gact act_csum act_bpf act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_hfsc sch_ingress ath10k_pci ath10k_core ath mac80211 cfg80211 compat cryptodev xt_set ip_set_list_set ip_set_hash_netiface ip_set_hash_netport ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set ip6t_NPT ip6t_MASQUERADE nf_nat_masquerade_ipv6 nf_nat nf_conntrack ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_raw ip6table_mangle ip6table_filter ip6_tables pppoatm ppp_generic slhc nfsd nfsv3 msdos ip_gre gre ifb sit ip6_tunnel tunnel6 tunnel4 ip_tunnel veth tun snd_compress snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_rawmidi snd_seq_device snd_hwdep snd soundcore rxkad udf crc_itu_t ntfs nfs_layout_nfsv41_files nfsv4 nfs auth_rpcgss oid_registry lockd sunrpc grace minix isofs hfsplus hfs cramfs configfs cifs autofs4 kafs af_rxrpc dns_resolver dm_crypt dm_mirror dm_region_hash dm_log dm_mod br2684 atm multipath fscache raid456 async_raid6_recov async_pq async_xor async_memcpy async_tx raid10 raid1 raid0 linear md_mod xt_NFLOG x_tables nfnetlink_log nfnetlink nls_utf8 nls_koi8_r nls_cp1255 nls_iso8859_6 nls_iso8859_2 nls_iso8859_15 nls_iso8859_13 nls_cp932 nls_cp866 nls_cp864 nls_cp862 nls_cp852 nls_cp850 nls_cp775 nls_cp1251 nls_cp1250 xts algif_skcipher algif_hash af_alg sha512_generic sha256_generic sha1_generic seqiv jitterentropy_rng drbg pcbc md5 md4 hmac gf128mul fcrypt ecb des_generic ctr cmac ccm cbc authenc usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_hcd uhci_hcd ahci libahci libata ehci_fsl ehci_platform ehci_hcd sd_mod scsi_mod fsl_mph_dr_of xfs libcrc32c reiserfs jfs f2fs ext4 jbd2 mbcache exfat button_hotplug input_core usbcore usb_common mii aead crypto_null
Jan  7 11:05:07 localhost kernel: [10237.642712] CPU: 0 PID: 1006 Comm: btrfs-cleaner Not tainted 4.4.106-56ef06674a2579d8488bcbf4fe98e926-3 #1
Jan  7 11:05:07 localhost kernel: [10237.642720] task: da8bd140 ti: de9a4000 task.ti: de9a4000
Jan  7 11:05:07 localhost kernel: [10237.642725] NIP: c01c5500 LR: c01c5500 CTR: 00000000
Jan  7 11:05:07 localhost kernel: [10237.642731] REGS: de9a5b40 TRAP: 0700   Not tainted  (4.4.106-56ef06674a2579d8488bcbf4fe98e926-3)
Jan  7 11:05:07 localhost kernel: [10237.642735] MSR: 00029000 <CE,EE,ME>  CR: 28024042  XER: 00000000
Jan  7 11:05:07 localhost kernel: [10237.642747]
Jan  7 11:05:07 localhost kernel: [10237.642747] GPR00: c01c5500 de9a5bf0 da8bd140 00000025 dedc237c dedc2ee8 00000035 00029000
Jan  7 11:05:07 localhost kernel: [10237.642747] GPR08: 00000007 00000000 00000000 00001e5b 44024044 00000000 00000000 de9fe000
Jan  7 11:05:07 localhost kernel: [10237.642747] GPR16: 00000001 00000000 00005180 253a1000 00000000 da439000 de955800 c7c42780
Jan  7 11:05:07 localhost kernel: [10237.642747] GPR24: 00000000 fffffffb 00000000 00000000 00000000 00000000 00000000 c04f2acc
Jan  7 11:05:07 localhost kernel: [10237.642804] NIP [c01c5500] __btrfs_free_extent+0x490/0xfe8
Jan  7 11:05:07 localhost kernel: [10237.642811] LR [c01c5500] __btrfs_free_extent+0x490/0xfe8
Jan  7 11:05:07 localhost kernel: [10237.642815] Call Trace:
Jan  7 11:05:07 localhost kernel: [10237.642822] [de9a5bf0] [c01c5500] __btrfs_free_extent+0x490/0xfe8 (unreliable)
Jan  7 11:05:07 localhost kernel: [10237.642834] [de9a5ce0] [c01cadb4] __btrfs_run_delayed_refs.constprop.33+0x994/0x111c
Jan  7 11:05:07 localhost kernel: [10237.642842] [de9a5dc0] [c01cdb30] btrfs_run_delayed_refs+0x94/0x278
Jan  7 11:05:07 localhost kernel: [10237.642851] [de9a5e10] [c01e5834] btrfs_should_end_transaction+0x6c/0x90
Jan  7 11:05:07 localhost kernel: [10237.642858] [de9a5e20] [c01cbda4] btrfs_drop_snapshot+0x4d8/0x890
Jan  7 11:05:07 localhost kernel: [10237.642866] [de9a5eb0] [c01e6f4c] btrfs_clean_one_deleted_snapshot+0xd0/0xec
Jan  7 11:05:07 localhost kernel: [10237.642876] [de9a5ed0] [c01dc18c] cleaner_kthread+0x16c/0x1a8
Jan  7 11:05:07 localhost kernel: [10237.642886] [de9a5ef0] [c004551c] kthread+0xe0/0xe4
Jan  7 11:05:07 localhost kernel: [10237.642896] [de9a5f40] [c000daf0] ret_from_kernel_thread+0x5c/0x64
Jan  7 11:05:07 localhost kernel: [10237.642900] Instruction dump:
Jan  7 11:05:07 localhost kernel: [10237.642905] 7d005028 7d074b78 7ce0512d 40a2fff4 7c0004ac 710a0004 40a2001c 3c60c059
Jan  7 11:05:07 localhost kernel: [10237.642918] 7f24cb78 3863fd1c 4cc63182 4830fdc5 <0fe00000> 7ea3ab78 7ec4b378 7fe5fb78
Jan  7 11:05:07 localhost kernel: [10237.642932] ---[ end trace 5b6ec4a59ff4fa58 ]---
Jan  7 11:05:07 localhost kernel: [10237.651515] BTRFS info (device mmcblk0p2): forced readonly

Zajímavé, že tohle mám z /var/log/messages v tom kontejneru.

Test doběhl, žádná chyba:

worker /etc/portage # badblocks -svn /dev/sdb
Hledají se špatné bloky v nedestruktivním režimu čtení i zápis
Od bloku 0 do 30981119
Hledají se špatné bloky (nedestruktivní test čtení i zápisu)
Zkouším s náhodným vzorkem: hotovo                                               
Průchod dokončen, nalezeno 0 špatných bloků (0/0/0 chyb).
worker /etc/portage #

Takže jsem zpět na ubifs. Mosquitto, bc-gateway a lxc utility doinstalovány. Router aktualizován na 3.9.1 a homeassistant zase jede.

Kdy zase přemigruji na brtfs nedokáži říct, karta vypadá OK a ta teorie se zářením se mi vůbec nelíbí. V pracovním NB mám 128GB SD kartu, která mi rozšiřuje kapacitu úložiště a po dvou letech stále šlape bez chyb. Předtím tam byla 64GB karta, taky žádná chyba. Ale obě byly na ext4.

EDIT:
Někdy před vánoci nám prasklá žárovka vyrazila hlavní jistič. Možná to mohlo mít nějaký vliv. Netuším, jak se v těchto případech btrfs chová, zda se může až tak strašně rozbít.

Nechal jsem proběhnout badblocks -w. Žádná chyba na kartě.

worker /home/marian # badblocks -ws /dev/sdb
Zkouším se vzorkem 0xaa: hotovo
Čtení a porovnání: hotovo
Zkouším se vzorkem 0x55: hotovo
Čtení a porovnání: hotovo
Zkouším se vzorkem 0xff: hotovo
Čtení a porovnání: hotovo
Zkouším se vzorkem 0x00: hotovo
Čtení a porovnání: hotovo
worker /home/marian # 

Že by to záhadné záření?

Záhadné? Ani moc ne. Na internetu si můžete dohledat docela dost studií na to kolik poškozených dat za jakou dobu kosmické záření způsobuje jak v ram tak v úložištích různého typu. Jedná se o velmi malé šance, ale čím déle paměť běží, tím vyšší je pravděpodobnost, že se vyskytne kombinovaná chyba kterou souborový systém není schopen vyřešit. Ale samozřejmě není to univerzální odpověď. Já jí uváděl spíše jako pro úplnost, očekával jsem poškozenou kartu (myšleno, standardně se tímto problémem skoro nikdo nezabývá).

Pokud se karta zdá být v pořádku, tak je pravděpodobnější podle mě náhlé poškození při výpadku. Nebyl jsem součástí týmu když se vyvíjel Turris 1.x a tedy nevím jak moc se testoval běh z karty. Vámi zmíněný výpadek mohl klidně tento problém způsobit a to brzkým odpojením napájení kartě kde se ještě plně neusadily zapsaná data. Takovýmto způsobem mohla být poškozen strom právě v mountnutém rootu, což by i vysvětlovalo proč ostatní snapshoty jsou v pořádku. Poradím se s hardweráři ale to, že nevíme jak se router bude dlouhodobě s sd kartou chovat je i jeden z důvodů proč nechceme prohlásit btrfs na Turrisu za stabilní a podporované, prozatím se stále jedná o funkcionalitu v testování.

No čekal bych, že si s tím FS poradí. Na ext3/4 se mi tohle nikdy nestalo. Jediný problém, který jsem ext3/4 kdy měl, byl způsoben vadnou RAM.

Kartu jsem vrátil do routeru a dnes ráno znova přemigroval na btrfs. Snad se to nebude opakovat.

BTW, v případě problémů - jak můžu zakázat boot z karty bez toho, abych musel kartu vytahovat? Protože to je pro mne kapku komplikovanější operace.

Moje zkušenost je, že na vytržení sdkarty je ext taky náchylné. Možná, že jen o něco méně, protože má za sebou více vývoje, ale obecně se jedná o problém životnosti. Btrfs se snaží být nenáročné na flash paměti a tedy automaticky detekuje ssd mód a v takovém případě nezapisuje zálohu indexů která je právě v některých okrajových případech kdy dojde k poškození nutná. Toto chování je možné potlačit (dokonce tu na fóru je někde i odkaz jak na to, jen to nemůžu najít), ale v takovém případě se snižuje potenciální životnost karty na téměř polovinu.

Můžete upravit příkaz kterým se router bootuje. Pomocí příkazu fw_printenv si můžete zobrazit co v routeru je právě nastavené a pomoci příkazu fw_setenv to můžete editovat. Ale jedná se o zásah který vám může router rozbít a proto tu nechci psát jak na to. Pokud více jak funguje u-boot tak to zvládnete sám, pokud ne tak raději vytahujte kartu.

Aha. Já myslel, že stačí jen nastavit nějakou proměnnou. A jak tak koukám do kódu btrfs_migrate, je to složitější. Ale nic co bych nedokázal rozbít :smiley:

Nebyl by problém udělal shell script, který by dle požadavku upravil “bootcmd”.

Místo

then run mmcboot; else run ubiboot;

tam dát

then run ubiboot; else run ubiboot;

a bylo by vymalováno.

Můžete zkusit přidat issue tady: Issues · Turris / Turris OS / Turris OS packages · GitLab
Ale obecně si nemyslím, že je to velký usecase který potřebujeme zabezpečit.

Jinak proč rovnou nezahodit celý if? Stejně pokud to dáte do skriptu tak to znamená přepsat celý řádek a tedy proč rovnou neudělat dva rozumné příkazy. Ale ano to by fungovalo, jen vás prosím o to nepsat sem přesně postup (přesně příkaz) aby lidé kteří netuší jak to funguje se nedostali do ouzkých (tohle je něco co factory reset neopraví a ani přehrání z flash karty a tedy co tam kdo zničí tak už je nenávratně zničeno).

Tohle je z mého pohledu nejbezpečnější. Ale budu případně řešit až pokud se zase něco pokazí.
Mezitím možná kouknu na nějakou vhodnou mini UPS. Ideálně něco bez baterie, jen s kondenzátorem. Ale na nic vhodného jsem zatím nenarazil.

Co se týká bootu z SD karty nebo NAND … je to jednoduché.
@miska kdysi někde tady na fóru psal, že UBoot hack je psaný tak, že se rozhoduje … pokud přečte VFAT partitionu na SD kartě v oddílu 1 (mmcblk0p1) a najde na ní kernel (čili zimage a fdt), nabootuje z ní. Pokud ne, bootuje z NAND.

Čili bez vyndání karty to lze provést velmi snadno … smažete obsah mmcblk0p1 a bootujete z NAND. Nakopírujete obsah /boot z mmcblk0p2 na mmcblk0p1 (stačí fdt a zImage) a bootujete opět z SD karty.

Tuto kopii provádí i migrate_btrfs skript … lze si v něm vyhledat a nechat se volně inspirovat :slight_smile:

1 Like