Re: btrfs root fs started remounting ro

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

 



On Fri, Feb 7, 2020 at 10:52 AM John Hendy <jw.hendy@xxxxxxxxx> wrote:

> As an update, I'm now running off of a different drive (ssd, not the
> nvme) and I got the error again! I'm now inclined to think this might
> not be hardware after all, but something related to my setup or a bug
> with chromium.

Even if there's a Chromium bug, it should result in file system
corruption like what you're seeing.


> dmesg after trying to start chromium:
> - https://pastebin.com/CsCEQMJa

Could you post the entire dmesg, start to finish, for the boot in
which this first occurred?

This transid isn't realistic, in particular for a filesystem this new.

[   60.697438] BTRFS error (device dm-0): parent transid verify failed
on 202711384064 wanted 68719924810 found 448074
[   60.697457] BTRFS info (device dm-0): no csum found for inode 19064
start 2392064
[   60.697777] BTRFS warning (device dm-0): csum failed root 339 ino
19064 off 2392064 csum 0x8941f998 expected csum 0x00000000 mirror 1

Expected csum null? Are these files using chattr +C? Something like
this might help figure it out:

$ sudo btrfs insp inod -v 19064 /home
$ lsattr /path/to/that/file/

Report output for both.


> Thanks for any pointers, as it would now seem that my purchase of a
> new m2.sata may not buy my way out of this problem! While I didn't
> want to reinstall, at least new hardware is a simple fix. Now I'm
> worried there is a deeper issue bound to recur :(

Yep. And fixing Btrfs is not simple.

> > nvme0n1p3 is encrypted with dm-crypt/LUKS.

I don't think the problem is here, except that I sooner believe
there's a regression in dm-crypt or Btrfs with discards, than I
believe two different drives have discard related bugs.


> > The only thing I've stumbled on is that I have been mounting with
> > rd.luks.options=discard and that manually running fstrim is preferred.

This was the case for both the NVMe and SSD drives?

What was the kernel version this problem first appeared on with NVMe?
For the (new) SSD you're using 5.5.1, correct?

Can you correlate both corruption events to recent use of fstrim?

What are the make/model of both drives?

In the meantime, I suggest refreshing backups. Btrfs won't allow files
with checksums that it knows are corrupt to be copied to user space.
But it sounds like so far the only files affected are Chrome cache
files? If so this is relatively straight forward to get back to a
healthy file system. And then it's time to start iterating some of the
setup to find out what's causing the problem.


-- 
Chris Murphy



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux