Aw: Re: Re: Help needed with filesystem errors: parent transid verify failed
Hi Chris, > Gesendet: Dienstag, 30. März 2021 um 20:17 Uhr > Von: "Chris Murphy" > > On Tue, Mar 30, 2021 at 2:44 AM B A wrote: > > > > > Gesendet: Dienstag, 30. März 2021 um 00:07 Uhr > > > Von: "Chris Murphy" > > > […] > > > EVO or PRO? And what does its /proc/mounts line look like? > > > > Model is MZ-7TD500, which seems to be an EVO. Firmware is DXT08B0Q. > > For me smartctl reports > Device Model: Samsung SSD 840 EVO 250GB > Firmware Version: EXT0DB6Q > > Yours might be a PRO or it could just be a different era EVO. Last I > checked, Samsung had no firmware updates on their website for the 840 > EVO. While I'm aware of some minor firmware bugs related to smartctl > testing, so far I've done well over 100 pull the power cord tests > while doing heavy writes (with Btrfs), and have never had a problem. > So I'd say there's probably not a "per se" problem with this model. > Best guess is that since the leaves pass checksum, it's not > corruption, but some SSD equivalent of a misdirected write (?) if > that's possible. It just looks like these two leaves are in the wrong > place. I'd rather go with the theory you (indirectly) raised a few days ago that my RAM may misbehave (when you suggested I run memtest). This is rather possible because I had difficulties understanding my BIOS and at some point I have accidentally enabled some overclocking. As I know this may cause the RAM to misbehave (and I don't have ECC RAM), this may as well be the reason. > > > > Total_LBAs_Written? > > > > Raw value: > 92857573119 > > OK I'm at 33063832698 > > Well hopefully --repair will fix it (let us know either way) and if > not, then we'll see what Josef can come up with, or alternatively you > can just mkfs and restore from backups which will surely be faster. Sadly it didn't (see other e-mail) but I think I'll go for the latter (mkfs and restore from backups) as I *think* my backups are fine and I don't want to waste more of your time (unless Josef wants to get his changes tested). Thanks very much so far for the support and thanks for maintaining BTRFS :-) Kind regards, Chris
Re: Aw: Re: Re: Help needed with filesystem errors: parent transid verify failed
On 3/29/21 4:42 AM, B A wrote: Gesendet: Montag, 29. März 2021 um 08:09 Uhr Von: "Chris Murphy" An: "B A" , "Btrfs BTRFS" Cc: "Qu Wenruo" , "Josef Bacik" Betreff: Re: Re: Help needed with filesystem errors: parent transid verify failed […] What do you get for: btrfs insp dump-s -f /dev/dm-0 See attached file "btrfs_insp_dump-s_-f.txt" I'm on PTO this week so I'll be a little less responsive, but thankfully this is just the extent tree. First thing is to make sure you've backed everything up, and then you should be able to just do btrfs check --repair and it should fix it for you. However I've noticed some failure cases where it won't fix transid errors sometimes because it errors out trying to read the things. If that happens just let me know, I have a private branch with fsck changes to address this class of problems and I can point you at that. I'd rather wait to make sure the normal fsck won't work first tho, just in case. Thanks, Josef
Aw: Re: Re: Help needed with filesystem errors: parent transid verify failed
> Gesendet: Montag, 29. März 2021 um 08:09 Uhr > Von: "Chris Murphy" > An: "B A" , "Btrfs BTRFS" > Cc: "Qu Wenruo" , "Josef Bacik" > Betreff: Re: Re: Help needed with filesystem errors: parent transid verify > failed > […] > > What do you get for: > > btrfs insp dump-s -f /dev/dm-0 See attached file "btrfs_insp_dump-s_-f.txt" > Hopefully Qu or Josef will have an idea. > > -- > Chris Murphy Thanks again! Kind regards, Chrissuperblock: bytenr=65536, device=/dev/mapper/luks-ff6e174f-4cd3-42a7-8ee5-47005dd077dc - csum_type 0 (crc32c) csum_size 4 csum0x0fcf13cc [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid1a149bda-057d-4775-ba66-1bf259fce9a5 metadata_uuid 1a149bda-057d-4775-ba66-1bf259fce9a5 label fedora_chstpc-2 generation 2734487 root1144777555968 sys_array_size 129 chunk_root_generation 2708287 root_level 1 chunk_root 1144718917632 chunk_root_level1 log_root0 log_root_transid0 log_root_level 0 total_bytes 322120450048 bytes_used 247510102016 sectorsize 4096 nodesize16384 leafsize (deprecated) 16384 stripesize 4096 root_dir6 num_devices 1 compat_flags0x0 compat_ro_flags 0x0 incompat_flags 0x169 ( MIXED_BACKREF | COMPRESS_LZO | BIG_METADATA | EXTENDED_IREF | SKINNY_METADATA ) cache_generation2734487 uuid_tree_generation2734487 dev_item.uuid f7c9ee7f-0de1-49bb-a838-fdc9b4111331 dev_item.fsid 1a149bda-057d-4775-ba66-1bf259fce9a5 [match] dev_item.type 0 dev_item.total_bytes322120450048 dev_item.bytes_used 288903659520 dev_item.io_align 4096 dev_item.io_width 4096 dev_item.sector_size4096 dev_item.devid 1 dev_item.dev_group 0 dev_item.seek_speed 0 dev_item.bandwidth 0 dev_item.generation 0 sys_chunk_array[2048]: item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 1144718884864) length 33554432 owner 2 stripe_len 65536 type SYSTEM|DUP io_align 65536 io_width 65536 sector_size 4096 num_stripes 2 sub_stripes 1 stripe 0 devid 1 offset 1074790400 dev_uuid f7c9ee7f-0de1-49bb-a838-fdc9b4111331 stripe 1 devid 1 offset 1108344832 dev_uuid f7c9ee7f-0de1-49bb-a838-fdc9b4111331 backup_roots[4]: backup 0: backup_tree_root: 1144895651840 gen: 2734484level: 1 backup_chunk_root: 1144718917632 gen: 2708287level: 1 backup_extent_root: 1144891129856 gen: 2734484level: 2 backup_fs_root: 1145036898304 gen: 2734355level: 0 backup_dev_root:1144828215296 gen: 2734438level: 1 backup_csum_root: 1144889982976 gen: 2734484level: 2 backup_total_bytes: 322120450048 backup_bytes_used: 247427117056 backup_num_devices: 1 backup 1: backup_tree_root: 1144902451200 gen: 2734485level: 1 backup_chunk_root: 1144718917632 gen: 2708287level: 1 backup_extent_root: 1144897241088 gen: 2734485level: 2 backup_fs_root: 1145036898304 gen: 2734355level: 0 backup_dev_root:1144828215296 gen: 2734438level: 1 backup_csum_root: 1144891408384 gen: 2734485level: 2 backup_total_bytes: 322120450048 backup_bytes_used: 247439462400 backup_num_devices: 1 backup 2: backup_tree_root: 1144915836928 gen: 2734486level: 1 backup_chunk_root: 1144718917632 gen: 2708287level: 1 backup_extent_root: 1144753078272 gen: 2734486level: 2 backup_fs_root: 0 gen: 0 level: 0 backup_dev_root:1144771723264 gen: 2734486level: 1 backup_csum_root: 1144755093504 gen: 2734486level: 2 backup_total_bytes: 322120450048 backup_bytes_used: 247510102016 backup_num_devices: 1 backup 3: backup_tree_root: 1144777555968 gen: 2734487level: 1 backup_chunk_root: 1144718917632 gen: 2708287level: 1
