Re: csum questions

2013-09-27 Thread Hugo Mills
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? 


signature.asc
Description: Digital signature


Re: csum questions

2013-09-27 Thread Tom Gundersen
On Fri, Sep 27, 2013 at 4:25 PM, Hugo Mills h...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: csum questions

2013-09-27 Thread Zach Brown
  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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: csum questions

2013-09-27 Thread Chris Murphy

On Sep 27, 2013, at 11:51 AM, Zach Brown z...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: csum questions

2013-09-27 Thread Zach Brown
On Fri, Sep 27, 2013 at 12:47:57PM -0600, Chris Murphy wrote:
 
 On Sep 27, 2013, at 11:51 AM, Zach Brown z...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: csum questions

2013-09-27 Thread Chris Murphy

On Sep 27, 2013, at 1:13 PM, Zach Brown z...@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 z...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html