Re: Btrfs scrub failure for raid 6 kernel 4.3

[Waxhead <waxhead@online.no>]

Duncan wrote:
> Waxhead posted on Mon, 28 Dec 2015 03:04:33 +0100 as excerpted:
>
>> Duncan wrote:
>>> Waxhead posted on Mon, 28 Dec 2015 00:06:46 +0100 as excerpted:
>>>
>>>> btrfs scrub status /mnt
>>>> scrub status for 2832346e-0720-499f-8239-355534e5721b
>>>>            scrub started at Sun Mar 29 23:21:04 2015
>>>> Now here is the first worrying part... it says that scrub started at
>>>> Sun Mar 29.
>>> Hmm...  The status is stored in readable plain-text files in /var/lib/
>>> btrfs/scrub.status.*, where the * is the UUID.  If you check there, the
>>> start time (t_start) seems to be in POSIX time.
>>>
>>> Is it possible you were or are running the scrub from, for instance, a
>>> rescue image that might not set the system time correctly and that
>>> falls back to, say, the date the rescue image was created, if it can't
>>> get network connectivity or some such?
>>>
>> No I don't think so....
>>
>> # ls -la
>> /var/lib/btrfs/scrub.status.2832346e-0720-499f-8239-355534e5721b
>> -rw------- 1 root root 2315 Mar 29  2015
>> /var/lib/btrfs/scrub.status.2832346e-0720-499f-8239-355534e5721b
>>
>> # cat /var/lib/btrfs/scrub.status.2832346e-0720-499f-8239-355534e5721b
>> scrub status:1
>> 2832346e-0720-499f-8239-355534e5721b:1|[...]|t_start:1427664064|[...]
>>
>> # date Mon Dec 28 02:54:11 CET 2015
>>
>> Just to clear up any possible misunderstandings. I run this from a
>> simple netbook, and I have no idea why the date is off by so much.
> Well, both the file time and the unix time in the file say back in March,
> so whatever time syncing mechanism you use on that netbook, it evidently
> failed the boot you did that scrub.
>
The netbook is set up with NTP with pfSense as a host server. The 
pfSense is itself synched with multiple pools.
>> Note:  I have used the same USB drives (memory sticks really) to create
>> various configs of btrfs filesystems earlier. Could it be old metadata
>> in the filesystem that mess up things? Is not metadata stamped with the
>> UUID of the filesystem to prevent such things?
> Yes, metadata is stamped with UUID.  But one other possible explanation
> for the scrub time back in March might be if you were already playing
> with it back then, and somehow you have a USB stick with a filesystem
> from back then that... somehow... has the same UUID as the one you're
> experimenting on today.
yes, I  have played around with these usb sticks for a long time. 
Probably also before march 29.
>
> Don't ask me how it could get the same UUID.  I don't understand it
> either.  But if it did somehow happen, btrfs would be /very/ confused,
> and crashing scrubs and further data corruption could certainly result.
What if my use of dd accidentally trashed some important part of the new 
filesystem and btrfs therefore thinks a older version of the filesystem 
is the current one? If UUID's are in every metadatablock I find that 
pretty hard to believe. What if the UUID==0 ? is this accounted for?
> Of course if you weren't experimenting with btrfs on these devices back
> at the end of March and there's absolutely no way they could have gotten
> btrfs on them until say October or whenever, then we're back to the date
> somehow being wrong for that scrub, and having to look elsewhere for why
> scrub is crashing.
>
No, by all means - I tried a lot of weird stuff on those usb sticks way 
before march so they defiantly had a (multi disk) btrfs filesystem on 
them before.