Hi guys, I have some questions about btrfs'' handling of invalid csums. For the sake of argument I''m assuming no raid or anything like that (so only one copy exists of every file). When I try to access a file whose csum does not match, btrfs logs an error and refuses access to the file. I have two questions about this: 1) What happens to the file. Will btrfs just leave it alone, or will it be deleted from disk (I seem to remember reading this somewhere, just want to confirm)? 2) How may I tell btrfs to ignore all csums and just assume they are all correct? The reason for wanting this is in case the csum is garbled and the file is intact, or the csum is correct and the file is only partially garbled, but may still contain useful data. Any help would be greatly appreciated. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 27, 2013 at 04:22:16PM +0200, Tom Gundersen wrote:> Hi guys, > > I have some questions about btrfs'' handling of invalid csums. > > For the sake of argument I''m assuming no raid or anything like that > (so only one copy exists of every file). > > When I try to access a file whose csum does not match, btrfs logs an > error and refuses access to the file. I have two questions about this: > > 1) What happens to the file. Will btrfs just leave it alone, or will > it be deleted from disk (I seem to remember reading this somewhere, > just want to confirm)?It''s left there.> 2) How may I tell btrfs to ignore all csums and just assume they are > all correct? The reason for wanting this is in case the csum is > garbled and the file is intact, or the csum is correct and the file is > only partially garbled, but may still contain useful data.You can''t, right now. There''s discussion on IRC about this very point right now. :) Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- A clear conscience. Where did you get this taste --- for luxuries, Bernard?
On Fri, Sep 27, 2013 at 4:25 PM, Hugo Mills <hugo@carfax.org.uk> wrote:> On Fri, Sep 27, 2013 at 04:22:16PM +0200, Tom Gundersen wrote: >> 1) What happens to the file. Will btrfs just leave it alone, or will >> it be deleted from disk (I seem to remember reading this somewhere, >> just want to confirm)? > > It''s left there.Good to know :-)>> 2) How may I tell btrfs to ignore all csums and just assume they are >> all correct? The reason for wanting this is in case the csum is >> garbled and the file is intact, or the csum is correct and the file is >> only partially garbled, but may still contain useful data. > > You can''t, right now. There''s discussion on IRC about this very > point right now. :)/me joins Thanks. Tom -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > 2) How may I tell btrfs to ignore all csums and just assume they are > > all correct? The reason for wanting this is in case the csum is > > garbled and the file is intact, or the csum is correct and the file is > > only partially garbled, but may still contain useful data. > > You can''t, right now. There''s discussion on IRC about this very > point right now. :)Well, hold on. Yes, you can''t tell it to just not check checksums. But keep reading. It sounds like he thinks that *any* reads to the file will error once any checksum has failed. Surely that''s not true, you can do use like dd conv=noerror and read all the extents of the file whose checksums are still valid. - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sep 27, 2013, at 11:51 AM, Zach Brown <zab@redhat.com> wrote:>>> 2) How may I tell btrfs to ignore all csums and just assume they are >>> all correct? The reason for wanting this is in case the csum is >>> garbled and the file is intact, or the csum is correct and the file is >>> only partially garbled, but may still contain useful data. >> >> You can''t, right now. There''s discussion on IRC about this very >> point right now. :) > > Well, hold on. Yes, you can''t tell it to just not check checksums. > > But keep reading. It sounds like he thinks that *any* reads to the file > will error once any checksum has failed. Surely that''s not true, you > can do use like dd conv=noerror and read all the extents of the file > whose checksums are still valid.Would that get me an identically sized copy of the file, such as it is? Or is some piece, identified as corrupt, is dropped in the copy? If I get the whole file intact with just a bit flip, or bad sector data, that has a decent change of being fixed in a supporting application. If a whole extent is dropped, then the file is almost certainly useless. Big difference. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 27, 2013 at 12:47:57PM -0600, Chris Murphy wrote:> > On Sep 27, 2013, at 11:51 AM, Zach Brown <zab@redhat.com> wrote: > > >>> 2) How may I tell btrfs to ignore all csums and just assume they are > >>> all correct? The reason for wanting this is in case the csum is > >>> garbled and the file is intact, or the csum is correct and the file is > >>> only partially garbled, but may still contain useful data. > >> > >> You can''t, right now. There''s discussion on IRC about this very > >> point right now. :) > > > > Well, hold on. Yes, you can''t tell it to just not check checksums. > > > > But keep reading. It sounds like he thinks that *any* reads to the file > > will error once any checksum has failed. Surely that''s not true, you > > can do use like dd conv=noerror and read all the extents of the file > > whose checksums are still valid. > > Would that get me an identically sized copy of the file, such as it is?As far as I know, yes. - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sep 27, 2013, at 1:13 PM, Zach Brown <zab@redhat.com> wrote:> On Fri, Sep 27, 2013 at 12:47:57PM -0600, Chris Murphy wrote: >> >> On Sep 27, 2013, at 11:51 AM, Zach Brown <zab@redhat.com> wrote: >> >>>>> 2) How may I tell btrfs to ignore all csums and just assume they are >>>>> all correct? The reason for wanting this is in case the csum is >>>>> garbled and the file is intact, or the csum is correct and the file is >>>>> only partially garbled, but may still contain useful data. >>>> >>>> You can''t, right now. There''s discussion on IRC about this very >>>> point right now. :) >>> >>> Well, hold on. Yes, you can''t tell it to just not check checksums. >>> >>> But keep reading. It sounds like he thinks that *any* reads to the file >>> will error once any checksum has failed. Surely that''s not true, you >>> can do use like dd conv=noerror and read all the extents of the file >>> whose checksums are still valid. >> >> Would that get me an identically sized copy of the file, such as it is? > > As far as I know, yes.OK this part of what you said made my eyebrows raise: "read all the extents of the file whose checksums are still valid" because it implied that extents with invalid checksums aren''t read. And that would be a much bigger problem than the original corruption. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html