Thanks for the replies. Good to know it's working as expected, and I'm glad restore permits restoring a corrupt file since this may be desirable in some cases, but agree with Chris that it would be nice to get a warning if corruption is found or suspected. Jorge On Thu, Nov 23, 2017 at 7:43 AM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > On 2017年11月23日 13:25, Chris Murphy wrote: >> On Wed, Nov 22, 2017 at 12:18 PM, Jorge Bastos <jorge.mrbastos@xxxxxxxxx> wrote: >>> Hello, >>> >>> While doing btrfs checksum testing I purposely corrupted a file and >>> got the expect I/O error when trying to copy it, I also tested btrfs >>> restore to see if I could recover a known corrupt file and it did copy >>> it but there was no checksum error or warning. I used btrfs restore -v >>> >>> Is this expect behavior or should restore warn about checksum failures? >>> >>> Kernel used was 4.13.13, btrfs-progs v4.13.2 >> >> I think it's expected. "The checks done by restore are less strict" >> from the man page. Although it'd be nice if -v option at least could >> flag such files as possibly being corrupt. >> > I think people always consider "btrfs restore" as a tool to "restore" data. > > The proper name of it should be "salvage" and moved under "btrfs > rescue", to reduce the confusion. > > Thanks, > Qu > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
