On Mon, Jan 11, 2021 at 12:24 AM Sreyan Chakravarty <sreyan32@xxxxxxxxx> wrote: > > On Sun, Jan 10, 2021 at 3:10 AM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > Sreyan, is the drive that this file system is on the same drive as in > > this reported thread? > > https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx/thread/DJWIOXUOSAAHAAXSUTKREV452QDCXV3D/#6UDYNNWOC23NJKSLMIABSAU4QFYANSRB > > > > > > Yes it is the same drive. > > Does that mean something is wrong with the drive ? Short version: Josef (Btrfs dev) and I agree there's probably something wrong with the drive. The advice is to replace it, just because trying to investigate further isn't worth your time, and also necessarily puts your data at risk. Longer version: LVM thinp uses device-mapper as its backend to do all the work, and we see checksum errors in the months old report. Where LVM thick has a simpler on-disk format, so it's not as likely to discover such a problem. And LUKS/dm-crypt is also using device-mapper as its backend to do all work. So the two problems have two things in common: the drive, and device-mapper. It's more probable there's an issue with the drive, just because if there was a problem with device-mapper, we'd have dozens of reports of it at the rate you're seeing this problem once every couple of months (if that trend holds). Is it possible LVM+ext4 on this same drive is more reliable? I think that's specious. The problem can be masked due to much less stringent integrity guarantees, i.e. there are no data checksums. Since the data is overwhelmingly the largest target for corruption, just being a much bigger volume compared to file system metadata. All things being equal, there's a greater chance the problem affects data. On the other hand, if it adversely impacts metadata, it could be true that e2fsck has a better chance of fixing the damage than btrfsck right now. Of course no fsck fixes your data. So if you keep using the drive, you're in a catch-22. Btrfs is more sensitive because everything is checksummed, so the good news is you'll be informed about it fairly quickly, the bad news is that it's harder to repair in this case. If you revert to LVM+ext4 the automatic fsck at startup might fix up these problems as they occur, but it's possible undetected data corruption shows up later or replicates into your backups. Regardless of what you decide to do, definitely keep frequent backups of anything important. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx
