* btrfs restore corrupt file
@ 2017-11-22 19:18 Jorge Bastos
2017-11-23 5:25 ` Chris Murphy
2017-11-23 9:25 ` Duncan
0 siblings, 2 replies; 6+ messages in thread
From: Jorge Bastos @ 2017-11-22 19:18 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs restore corrupt file
2017-11-22 19:18 btrfs restore corrupt file Jorge Bastos
@ 2017-11-23 5:25 ` Chris Murphy
2017-11-23 7:43 ` Qu Wenruo
2017-11-23 9:25 ` Duncan
1 sibling, 1 reply; 6+ messages in thread
From: Chris Murphy @ 2017-11-23 5:25 UTC (permalink / raw)
To: Jorge Bastos; +Cc: Btrfs BTRFS
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs restore corrupt file
2017-11-23 5:25 ` Chris Murphy
@ 2017-11-23 7:43 ` Qu Wenruo
2017-11-23 9:08 ` Jorge Bastos
0 siblings, 1 reply; 6+ messages in thread
From: Qu Wenruo @ 2017-11-23 7:43 UTC (permalink / raw)
To: Chris Murphy, Jorge Bastos; +Cc: Btrfs BTRFS
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs restore corrupt file
2017-11-23 7:43 ` Qu Wenruo
@ 2017-11-23 9:08 ` Jorge Bastos
0 siblings, 0 replies; 6+ messages in thread
From: Jorge Bastos @ 2017-11-23 9:08 UTC (permalink / raw)
To: Qu Wenruo; +Cc: Chris Murphy, Btrfs BTRFS
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs restore corrupt file
2017-11-22 19:18 btrfs restore corrupt file Jorge Bastos
2017-11-23 5:25 ` Chris Murphy
@ 2017-11-23 9:25 ` Duncan
1 sibling, 0 replies; 6+ messages in thread
From: Duncan @ 2017-11-23 9:25 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* btrfs restore corrupt file
@ 2017-11-22 18:46 Jorge Bastos
0 siblings, 0 replies; 6+ messages in thread
From: Jorge Bastos @ 2017-11-22 18:46 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-11-23 9:25 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-22 19:18 btrfs restore corrupt file Jorge Bastos
2017-11-23 5:25 ` Chris Murphy
2017-11-23 7:43 ` Qu Wenruo
2017-11-23 9:08 ` Jorge Bastos
2017-11-23 9:25 ` Duncan
-- strict thread matches above, loose matches on Subject: below --
2017-11-22 18:46 Jorge Bastos
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.