Re: 3.15-rc5 btrfs send/receive corruption errors? Does scrub

Re: 3.15-rc5 btrfs send/receive corruption errors? Does scrub

[Marc MERLIN]

warn of silent corruption?
Reply-To: 
In-Reply-To: <E1WiphR-0003MN-50@legolas.merlins.org>
 <20140510224249.GA15909@merlins.org>
X-Sysadmin: BOFH
X-URL: http://marc.merlins.org/

On Sat, May 10, 2014 at 03:42:49PM -0700, Marc MERLIN wrote:
> I tried with 3.14.3 and it went further, however it died with
> legolas:/mnt/btrfs_pool2# btrfs send  home_ro.20140507_10:00:01 | btrfs receive /mnt/btrfs_pool1/
> At subvol home_ro.20140507_10:00:01
> At subvol home_ro.20140507_10:00:01
> ERROR: send ioctl failed with -5: Input/output error
> ERROR: unexpected EOF in stream.
> 
> I'll look up -5 later when I have time, but I guess there is a problem
> on the source that is causing copies to fail with both kernels?

This brings me back to the earlier question:

When my other FS died, scrub ran ok just earlier.

Now, having 2 btrfs sends (not incremental, full) fail with 2 kernels
would indicate that something might be wrong on the source filesystem.

Yet, last night's scrub ran fine too:

On Fri, May 09, 2014 at 11:39:13AM -0700, Anacron wrote:
> /etc/cron.daily/btrfs-scrub:
> scrub device /dev/mapper/cryptroot (id 1) done
> 	scrub started at Fri May  9 06:09:14 2014 and finished after 19153 seconds
> 	total bytes scrubbed: 646.15GiB with 0 errors

So, does scrub actually make sure everything on my filesystem is sane,
or can it miss some kinds of corruptions?

I can't run btrfsck on the filesystem because it's mounted and I have no
backup FS to boot from now until I fix my SSD.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

Re: 3.15-rc5 btrfs send/receive corruption errors? Does scrub

[David Brown]

On Sat, May 10, 2014 at 04:57:18PM -0700, Marc MERLIN wrote:

>On Fri, May 09, 2014 at 11:39:13AM -0700, Anacron wrote:
>> /etc/cron.daily/btrfs-scrub:
>> scrub device /dev/mapper/cryptroot (id 1) done
>> 	scrub started at Fri May  9 06:09:14 2014 and finished after 19153 seconds
>> 	total bytes scrubbed: 646.15GiB with 0 errors
>
>So, does scrub actually make sure everything on my filesystem is sane,
>or can it miss some kinds of corruptions?

Does scrub make sure _anything_ on the filesystem is sane?  I guess it
would detect some failures because the tree is incorrect, but I
thought scrub was mostly about making sure the data match the
checksums.

Just curious, the future "online filesystem check", will that be part
of scrub, or another command.  It seems like it would be common to
want a faster integrity check that doesn't have to read all of the
data as well.

David

Re: 3.15-rc5 btrfs send/receive corruption errors? Does scrub

[Duncan]

Marc MERLIN posted on Sat, 10 May 2014 16:57:18 -0700 as excerpted:

> So, does scrub actually make sure everything on my filesystem is sane,
> or can it miss some kinds of corruptions?

Catching it here as well as the other thread...

All scrub does is verify the checksum (and replace bad versions with good 
versions where there's a good copy available to do so).

Scrub does NOT detect or fix faulty logic bug writes that never-the-less 
were properly checksummed, as the checksums can be perfectly valid on 
entirely invalid (meta)data.

Using an example from recent US political history, it's as if someone 
recorded the head of the US NSA assuring congress that it did not 
knowingly collect data on US citizens in the generic case, when a few 
months later we found out it was doing just that.  Now if that recording 
was checksummed, that checksum will normally still verify just fine 
today, even tho we know the claims in the recorded stream are 100% 
faulty.  Verifying the checksum can validate the recording hasn't been 
corrupted since it was stored, but it does nothing at all to verify the 
claims made in that recording, and is simply the wrong tool for the job 
if that's what you're trying to do.

Back on btrfs, if we were checksumming metadata and that metadata was 
faulty due to some now fixed bug, verifying the checksum simply verifies 
that the still-faulty metadata hasn't changed from when we stored it, not 
that the metadata isn't faulty in the first place.

-- 
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