Re: mount fails for btrfs filesystem, need help please.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Chris,

I have a "smartctl -l /dev/sda" running now.....

I'll read over your writing below... If I have questions or problems, I'll ask... otherwise, I'll report what happens.

Thanks!

George...


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
_______________________________________________
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




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux