[help needed] parent verity error on HDD

[help needed] parent verity error on HDD

[PranshuTheGamer]

I have a backup of my files on a hard drive with btrfs. Recently while
running something off the hard drive, it switched off by itself, and
then when i tried remounting it, it gave me this:

I would like to note that since the last successful mount, there
hasn't been any important writes to the disk.

> sudo mount /dev/sdc1 /run/media/shivangi/LV-01
[sudo] password for shivangi:
mount: /run/media/shivangi/LV-01: can't read superblock on /dev/sdc1.
       dmesg(1) may have more information after failed mount system call.

> sudo dmesg
[ 2049.529633] BTRFS: device /dev/sdc1 (8:33) using temp-fsid
0f830c0c-e975-4c8d-974a-d8cc94bf49e7
[ 2049.529643] BTRFS: device label LV-01 devid 1 transid 8301
/dev/sdc1 (8:33) scanned by mount (5669)
[ 2049.687040] BTRFS info (device sdc1): first mount of filesystem
d9441c01-827c-47da-890c-491213f25ddb
[ 2049.687057] BTRFS info (device sdc1): using crc32c (crc32c-x86)
checksum algorithm
[ 2049.687061] BTRFS info (device sdc1): using free-space-tree
[ 2049.976371] BTRFS info (device sdc1): bdev /dev/sdc1 errs: wr 0, rd
0, flush 0, corrupt 5, gen 0
[ 2052.052541] BTRFS error (device sdc1): parent transid verify failed
on logical 120422400 mirror 1 wanted 8301 found 5836
[ 2052.083206] BTRFS error (device sdc1): parent transid verify failed
on logical 120422400 mirror 2 wanted 8301 found 5836
[ 2052.083258] BTRFS error (device sdc1): failed to read block groups: -5
[ 2052.085958] BTRFS error (device sdc1): open_ctree failed: -5

> sudo btrfs check --readonly /dev/sdc1
Opening filesystem to check...
parent transid verify failed on 120422400 wanted 8301 found 5836
parent transid verify failed on 120422400 wanted 8301 found 5836
parent transid verify failed on 120422400 wanted 8301 found 5836
Ignoring transid failure
parent transid verify failed on 120619008 wanted 8301 found 5836
parent transid verify failed on 120619008 wanted 8301 found 5836
parent transid verify failed on 120619008 wanted 8301 found 5836
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=40599552 item=4 parent
level=2 child bytenr=120619008 child level=0
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system

kernel info:
6.15.4-arch2-1

Please help me fix the drive.

Re: [help needed] parent verity error on HDD

[PranshuTheGamer]

extra information:

> sudo btrfs rescue chunk-recover /dev/sdc1
Scanning: 789579710464 in dev0scan chunk headers error

Re: [help needed] parent verity error on HDD

[PranshuTheGamer]

extra extra information:

> sudo btrfs-find-root /dev/disk/by-label/LV-01
parent transid verify failed on 120422400 wanted 8301 found 5836
parent transid verify failed on 120422400 wanted 8301 found 5836
ERROR: failed to read block groups: Input/output error
Superblock thinks the generation is 8301
Superblock thinks the level is 1
Found tree root at 119324672 gen 8301 level 1
Well block 35749888(gen: 8300 level: 1) seems good, but
generation/level doesn't match, want gen: 8301 level: 1

> sudo btrfs restore -D -s -S -x -m -i  --path-regex "^.*$" \
/dev/disk/by-label/LV-01 .
This is a dry-run, no files are going to be restored
ERROR: failed to change owner of './Backups/Other/school/G12
School/eng/hugo-portfolio/themes/risotto/exampleSite/content/_index.md':
No such file or directory
ERROR: failed to change owner of
'./Snapshots/Backups/Other-1748279502.547062230_2025-05-26_20:11:42/school/G12
School/eng/hugo-portfolio/themes/risotto/exampleSite/content/_index.md':
No such file or directory
[1]    11852 segmentation fault  sudo btrfs restore -D -s -S -x -m -i
--path-regex "^.*$"  .

Re: [help needed] parent verity error on HDD

[PranshuTheGamer]

Reply to this email thread:
https://lore.kernel.org/linux-btrfs/CAPYq2E0yh0cfM9AXNqjHpz9dLnzRa3xZ76vJEKqsM9-jaJpktQ@mail.gmail.com/T/#u

Re: [help needed] parent verity error on HDD

[Chris Murphy]

On Tue, Jul 8, 2025, at 12:05 PM, Pranshu Tanwar wrote:
>> Copy files out with -o ro,rescue=all and reformat. The problem is probably the result of a drive firmware bug. Keep backups!
> It did not mount, I got the files with btrfs restore to work in a 
> snapshot of a shared snapshot to then restore the files. I am now 
> working on rebuilding the drive with safer mount options for both 
> drives.
>
> These are the options I came up with:
>
> /etc/udisks2/mount_options.conf
> ---
> [defaults]
> btrfs_allow=compress,compress-force,datacow,nodatacow,datasum,nodatasum,autodefrag,noautodefrag,degraded,device,discard,nodiscard,subvol,subvolid,space_cache,commit,noatime,flushoncommit,noflushoncommit,barrier,nobarrier
> btrfs_defaults=commit=1,noatime,compress=zstd,flushoncommit,barrier

I don't know how udisks2/mount_options.conf affects anything. It should have no effect on the root file system. Anyway, you really want to use either upstream default mount options or your distribution's default mount options. You will run into trouble much faster otherwise.

>
> /etc/udev/rules.d/99-disable-write-cache.rules
> ---
> ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd[a-z]", 
> ENV{ID_USB_DRIVER}=="usb-storage", RUN+="/sbin/hdparm -W0 /dev/%k"
>
> But turning write caching off in hdparm is painfully slow, so for now 
> I've commented it out, relying solely on flushoncommit and commit=1

I don't think you'll be happy with the performance of commit=1 , it's too frequent. If there's a firmware bug resulting in flush or FUA transiently being ignored, then decreasing the commit interval just makes it more likely you'll run into a problem.

In my opinion the solution is frequent backups. Btrfs snapshots and send-receive make this quite cheap to do often. But any backup solution that you understand and have tested restore is the one you should use.

Best to reply to the list so responses are archived and everyone can chime in if they want.


-- 
Chris Murphy

Re: [help needed] parent verity error on HDD

[Pranshu Tanwar]

[-- Attachment #1.1: Type: text/plain, Size: 770 bytes --]

> I don't know how udisks2/mount_options.conf affects anything. It should have no effect on the root file system. Anyway, you really want to use either upstream default mount options or your distribution's default mount options. You will run into trouble much faster otherwise.
Its not my root filesystem, I keep two external hard drives mirrored with btrfs snapshots. One of those with the latest changes got corrupted due to being unplugged.


> I don't think you'll be happy with the performance of commit=1 , it's too frequent. If there's a firmware bug resulting in flush or FUA transiently being ignored, then decreasing the commit interval just makes it more likely you'll run into a problem.
I mean its alright, it freezes every once in a while but its fine

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]