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@xxxxxxxxxxxxxxxxx> Subject: Re: mount fails for btrfs filesystem, need help please. To: "For releases" <test@xxxxxxxxxxxxxxxxxxxxxxx> Message-ID: <efeb6908-565f-44ae-8cda-f487266c22d4@xxxxxxxxxxxxxxxx> 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 _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
