On 22/07/2020 00:05, Qu Wenruo wrote: > > > On 2020/7/21 下午11:10, Josef Bacik wrote: ... >> - skip_sum = BTRFS_I(inode)->flags & BTRFS_INODE_NODATASUM; >> + skip_sum = (BTRFS_I(inode)->flags & BTRFS_INODE_NODATASUM) || >> + btrfs_test_opt(fs_info, ONLYFS); > > This means, if onlyfs is spcified, csum is completely skipped even it > matches. > > I'm not yet determined whether it's preferred. > > On one hand, even at recovery, user may want csum verification to detect > bad copy if possible, but on the other hand, since user is doing data > salvage, bothering csum could only lead to extra error. If we are using this option then something very bad has happened to the filesystem. It would be useful to the user to know whether the checksum on the file being read is valid or not as a failed checksum will be a hint that the BAD THING has affected this file (maybe some extent got incorrectly overwritten by the content of another file, for example). It would tell the user that they may want to check the file in some other way or, at least, not rely on its contents. On the other hand, it may be that the file contents are fine, but the checksum has been corrupted, so it should also be possible the retrieve the contents anyway. Of course, in the face of unknown filesystem corruption, a valid checksum does not guarantee that the file is uncorrupted. But a bad checksum gives a strong hint that the file needs additional checking. I don't particularly care how the user finds out that the checksum is bad. In my earlier mail, I suggested that this option does not imply nodatasum and that the user has to specify nodatasum if that is what they want. However, I would also be happy with (for example) a warning in the logs if the checksum is not valid. By the way, is it possible to do a scrub while the filesystem is mounted with this option? What would happen, in that case, for either real bad sectors or checksum errors caused by the filesystem corruption?
