6:41 p.m.
Howdy,
Thanks to all who responded...
Chris,
I tried the superblock mount but that still fails. Then I tried the rescue=all mount. That
succeeded... I have copied all the files I need. From what I read, corrupted files get
copied too... and there were some which I removed from the copies.
From
"https://lists.fedoraproject.org/archives/search?mlist=users%40lists.fedoraproject.org&q=parent+transid+verify+failed"
I found some other commands that you wrote. I presume after unmounting this problematic
filesystem. Is it time to run them? I'm not sure what they'll do though.
btrfs rescue zero-log
btrfs check --repair --init-extent-tree
btrfs check --repair
Please advise.
Regards,
George...
Date: Mon, 22 Aug 2022 11:46:16 -0400
From: "Chris Murphy" <lists(a)colorremedies.com>
Subject: Re: mount fails for btrfs filesystem, need help please.
To: "For releases" <test(a)lists.fedoraproject.org>
Message-ID: <efeb6908-565f-44ae-8cda-f487266c22d4(a)www.fastmail.com>
Content-Type: text/plain
On Sun, Aug 21, 2022, at 11:02 PM, George R Goffe via test wrote:
Hi,
I started getting i/o error messages accessing this filesystem so I
rebooted the system. This might have been the wrong thing to do. This
subsequent boot went to maintenance mode due the filesystem's path
being in /etc/fstab.
I need some help with this please. Here is what mount says:
mount /dev/sda6 /opt.
kernel: BTRFS info (device sda6): flagging fs with big metadata feature
kernel: BTRFS info (device sda6): disk space caching is enabled
kernel: BTRFS info (device sda6): has skinny extents
kernel: BTRFS error (device sda6): parent transid verify failed on
148312850432 wanted 73476 found 73484
It usually means the hardware is not honoring the proper write order, by (occasionally)
ignoring flush/FUA. And in this case Btrfs can be really sensitive to the problem.
I suggest mounting with `-o ro,rescue=all` which gives the best chance of not changing the
file system, while getting access to important files you maybe don't have backed up -
and get them off while you can.
Also while you're at it you can do:
journalctl --since=yesterday -o short-monotonic --no-hostname | grep "Linux version\|
ata\|Btrfs\|BTRFS\|] hd\| scsi\| sd\| sdhci\| mmc\| nvme\| usb\| vd" -D
/mnt/root/var/log/journal
I'm assuming you mount the volume at /mnt.
You can copy off important files from /mnt/home/$username normally using any command
you're familiar with.
After that, you can umount the file system. And mount again with '-o
rescue=usebackuproot' and hopefully it finds a good backup root, and can fix itself.
If it gets confused again, it'll go read only to avoid making things worse.
--
Chris Murphy
8:30 p.m.
New subject: mount fails for btrfs filesystem, need help please.
On Mon, Aug 22, 2022, at 7:41 PM, George R Goffe via test wrote:
Howdy,
Thanks to all who responded...
Chris,
I tried the superblock mount but that still fails. Then I tried the
rescue=all mount. That succeeded... I have copied all the files I need.
From what I read, corrupted files get copied too... and there were some
which I removed from the copies.
It does disable data checksum verification, so it's possible. It's a valid option
to use the individual option method, leaving data checksumming in place, e.g.
mount -o ro,rescue=usebackuproot,nologreplay,ibadroots
in this case it will complain about corrupt file blocks and won't let them be copied
out. How this gets handled depends on the application - some applications stop at the
first bad file. Others continue reading the rest of the same file, then stop. Still others
continue reading all file blocks.
From
"https://lists.fedoraproject.org/archives/search?mlist=users%40lists.fedoraproject.org&q=parent+transid+verify+failed"
I found some other commands that you wrote. I presume after unmounting
this problematic filesystem. Is it time to run them?
Try "mount -o rescue=usebackuproot" this is also used by rescue=all, but permits
rw mount. If it works, the current damaged root tree will be replaced by a good one.
btrfs rescue zero-log
btrfs check --repair --init-extent-tree
btrfs check --repair
I don't think any of these are indicated for this problem.
Zero log is harmless, but the messages don't indicate a problem related to the tree
log.
Init extent tree is taking a big chance It might work, it might make things worse. And
it'll take a while. I'd just take advantage of the ro rescue mount to get your
data out such as it is. And then mkfs time. Wipe it and clean install, restore from
backups. It's the more reliable way of getting back to good.
But it's useful to look at logs over the last couple days to see if there's prior
evidence of problems and what they might be. Because it sounds to me like the hardware has
become unreliable in some way.
--
Chris Murphy
619
days inactive
620
days old
1 comments
2 participants
participants (2)
-
Chris Murphy -
George R Goffe