On Aug 11, 2017, at 1:07 PM, Robert Nichols <rnicholsNOSPAM@xxxxxxxxxxx> wrote:
>> Yeah he'd want to do an fsck -f and see if repairs are madestem.
>
> fsck checks filesystem metadata, not the content of files.
Chris might have been thinking of fsck -c or -k, which do various sorts of badblocks scans.
That’s still a poor alternative to strong data checksumming and Merkle tree structured filesystems, of course.
> LVM certainly makes the procedure harder. Figuring out what filesystem
> block corresponds to that LBA is still possible, but you have to examine
> the LV layout in /etc/lvm/backup/ and learn more than you probably wanted
> to know about LVM.
Linux kernel 4.8 added a feature called reverse mapping which is intended to solve this problem.
In principle, this will let you get a list of files that are known to be corrupted due to errors at the block layer, then fix it by removing or overwriting those files. The block layer, DM, LVM2, and filesystem layers will then be able to understand that those blocks are no longer corrupt, therefore the filesystem is fine, as are all the possible layers in between.
This understanding is based on a question I asked and had answered on the Stratis-Docs GitHub issue tracker:
https://github.com/stratis-storage/stratis-docs/issues/53
We’ll see how well it works in practice. It is certainly possible in principle: ZFS does this today.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
