btrfs restore corrupt file

btrfs restore corrupt file

[Jorge Bastos]

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

Thanks,
Jorge

Re: btrfs restore corrupt file

[Chris Murphy]

On Wed, Nov 22, 2017 at 12:18 PM, Jorge Bastos <jorge.mrbastos@gmail.com> 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.

-- 
Chris Murphy

Re: btrfs restore corrupt file

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 975 bytes --]



On 2017年11月23日 13:25, Chris Murphy wrote:
> On Wed, Nov 22, 2017 at 12:18 PM, Jorge Bastos <jorge.mrbastos@gmail.com> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

Re: btrfs restore corrupt file

[Jorge Bastos]

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@gmx.com> wrote:
>
>
> On 2017年11月23日 13:25, Chris Murphy wrote:
>> On Wed, Nov 22, 2017 at 12:18 PM, Jorge Bastos <jorge.mrbastos@gmail.com> 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
>

Re: btrfs restore corrupt file

[Duncan]

Jorge Bastos posted on Wed, 22 Nov 2017 19:18:59 +0000 as excerpted:

> 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

AFAIK it's expected.  The purpose of btrfs restore, after all, is to try 
to get at least some files back from a filesystem that is generally 
damaged and unable to mount, so acceptance of some possible damage to 
restored files as a tradeoff for being able to restore them *at* *all* is 
assumed.  It's not /supposed/ to be a substitute for having a proper 
backup in the first place, only something to try in case there was no 
backup and getting back a damaged file is better than getting back no 
file, or in case there was a backup, but it wasn't current, in which case 
the restored files can be verified against the backup, and those that 
differ can be examined to see if the difference is due to legitimate 
change, or corruption.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

btrfs restore corrupt file

[Jorge Bastos]

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 and there was no checksum error or warning, is this expect behavior
or should restore warn about checksum failures?

Kernel used was 4.13.13,  btrfs-progs v4.13.2

Thanks,
Jorge