linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [4.3-rc4] scrubbing aborts before finishing
@ 2015-10-22  8:41 Martin Steigerwald
  2015-10-31 11:10 ` Martin Steigerwald
  0 siblings, 1 reply; 9+ messages in thread
From: Martin Steigerwald @ 2015-10-22  8:41 UTC (permalink / raw)
  To: linux-btrfs

Hi!

I get this:

merkaba:~> btrfs scrub status -d /       
scrub status for […]
scrub device /dev/mapper/sata-debian (id 1) history
        scrub started at Thu Oct 22 10:05:49 2015 and was aborted after 00:00:00
        total bytes scrubbed: 0.00B with 0 errors
scrub device /dev/dm-2 (id 2) history
        scrub started at Thu Oct 22 10:05:49 2015 and was aborted after 00:01:30
        total bytes scrubbed: 23.81GiB with 0 errors

For / scrub aborts for sata SSD immediately.

For /home scrub aborts for both SSDs at some time.

merkaba:~> btrfs scrub status -d /home
scrub status for […]
scrub device /dev/mapper/msata-home (id 1) history
        scrub started at Thu Oct 22 10:09:37 2015 and was aborted after 00:01:31
        total bytes scrubbed: 22.03GiB with 0 errors
scrub device /dev/dm-3 (id 2) history
        scrub started at Thu Oct 22 10:09:37 2015 and was aborted after 00:03:34
        total bytes scrubbed: 53.30GiB with 0 errors

Also single volume BTRFS is affected:

merkaba:~> btrfs scrub status /daten
scrub status for […]
        scrub started at Thu Oct 22 10:36:38 2015 and was aborted after 00:00:00
        total bytes scrubbed: 0.00B with 0 errors


No errors in dmesg, btrfs device stat or smartctl -a.

Any known issue?

Thanks,
-- 
Martin

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.3-rc4] scrubbing aborts before finishing
  2015-10-22  8:41 [4.3-rc4] scrubbing aborts before finishing Martin Steigerwald
@ 2015-10-31 11:10 ` Martin Steigerwald
  2015-11-25 15:35   ` Martin Steigerwald
  0 siblings, 1 reply; 9+ messages in thread
From: Martin Steigerwald @ 2015-10-31 11:10 UTC (permalink / raw)
  To: linux-btrfs

Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald:
> I get this:
> 
> merkaba:~> btrfs scrub status -d /       
> scrub status for […]
> scrub device /dev/mapper/sata-debian (id 1) history
>         scrub started at Thu Oct 22 10:05:49 2015 and was aborted after 00:00:00
>         total bytes scrubbed: 0.00B with 0 errors
> scrub device /dev/dm-2 (id 2) history
>         scrub started at Thu Oct 22 10:05:49 2015 and was aborted after 00:01:30
>         total bytes scrubbed: 23.81GiB with 0 errors
> 
> For / scrub aborts for sata SSD immediately.
> 
> For /home scrub aborts for both SSDs at some time.
> 
> merkaba:~> btrfs scrub status -d /home
> scrub status for […]
> scrub device /dev/mapper/msata-home (id 1) history
>         scrub started at Thu Oct 22 10:09:37 2015 and was aborted after 00:01:31
>         total bytes scrubbed: 22.03GiB with 0 errors
> scrub device /dev/dm-3 (id 2) history
>         scrub started at Thu Oct 22 10:09:37 2015 and was aborted after 00:03:34
>         total bytes scrubbed: 53.30GiB with 0 errors
> 
> Also single volume BTRFS is affected:
> 
> merkaba:~> btrfs scrub status /daten
> scrub status for […]
>         scrub started at Thu Oct 22 10:36:38 2015 and was aborted after 00:00:00
>         total bytes scrubbed: 0.00B with 0 errors
> 
> 
> No errors in dmesg, btrfs device stat or smartctl -a.
> 
> Any known issue?

I am still seeing this in 4.3-rc7. It happens so that on one SSD BTRFS
doesn´t even start scrubbing. But in the end it aborts it scrubbing anyway.

I do not see any other issue so far. But I would really like to be able to
scrub my BTRFS filesystems completely again. Any hints? Any further
information needed? 

merkaba:~> btrfs scrub status -d /
scrub status for […]
scrub device /dev/dm-5 (id 1) history
        scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
        total bytes scrubbed: 0.00B with 0 errors
scrub device /dev/mapper/msata-debian (id 2) status
        scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:20
        total bytes scrubbed: 5.27GiB with 0 errors
merkaba:~> btrfs scrub status -d /
scrub status for […]
scrub device /dev/dm-5 (id 1) history
        scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
        total bytes scrubbed: 0.00B with 0 errors
scrub device /dev/mapper/msata-debian (id 2) status
        scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:25
        total bytes scrubbed: 6.59GiB with 0 errors
merkaba:~> btrfs scrub status -d /
scrub status for […]
scrub device /dev/dm-5 (id 1) history
        scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
        total bytes scrubbed: 0.00B with 0 errors
scrub device /dev/mapper/msata-debian (id 2) status
        scrub started at Sat Oct 31 11:58:45 2015, running for 00:01:25
        total bytes scrubbed: 21.97GiB with 0 errors
merkaba:~> btrfs scrub status -d /
scrub status for […]
scrub device /dev/dm-5 (id 1) history
        scrub started at Sat Oct 31 11:58:45 2015 and was aborted after 00:00:00
        total bytes scrubbed: 0.00B with 0 errors
scrub device /dev/mapper/msata-debian (id 2) history
        scrub started at Sat Oct 31 11:58:45 2015 and was aborted after 00:01:32
        total bytes scrubbed: 23.63GiB with 0 errors


For the sake of it I am going to btrfs check one of the filesystem where
BTRFS aborts scrubbing (which is all of the laptop filesystems, not only
the RAID 1 one).

I will use the /daten filesystem as I can unmount it during laptop runtime
easily. There scrubbing aborts immediately:

merkaba:~> btrfs scrub start /daten 
scrub started on /daten, fsid […] (pid=13861)
merkaba:~> btrfs scrub status /daten
scrub status for […]
        scrub started at Sat Oct 31 12:04:25 2015 and was aborted after 00:00:00
        total bytes scrubbed: 0.00B with 0 errors

It is single device:

merkaba:~> btrfs fi sh /daten
Label: 'daten'  uuid: […]
        Total devices 1 FS bytes used 227.23GiB
        devid    1 size 230.00GiB used 230.00GiB path /dev/mapper/msata-daten

btrfs-progs v4.2.2
merkaba:~> btrfs fi df /daten
Data, single: total=228.99GiB, used=226.79GiB
System, single: total=4.00MiB, used=48.00KiB
Metadata, single: total=1.01GiB, used=449.50MiB
GlobalReserve, single: total=160.00MiB, used=0.00B


I do not see any output in btrfs check that points to any issue:

merkaba:~> btrfs check /dev/msata/daten
Checking filesystem on /dev/msata/daten
UUID: 7918274f-e2ec-4983-bbb0-aa93ef95fcf7
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
found 243936530607 bytes used err is 0
total csum bytes: 237758932
total tree bytes: 471384064
total fs tree bytes: 116473856
total extent tree bytes: 78544896
btree space waste bytes: 57523323
file data blocks allocated: 422700576768
 referenced 243803443200
btrfs-progs v4.2.2

Thanks,
-- 
Martin

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.3-rc4] scrubbing aborts before finishing
  2015-10-31 11:10 ` Martin Steigerwald
@ 2015-11-25 15:35   ` Martin Steigerwald
  2015-11-26 16:39     ` Duncan
  2015-12-14  7:59     ` Martin Steigerwald
  0 siblings, 2 replies; 9+ messages in thread
From: Martin Steigerwald @ 2015-11-25 15:35 UTC (permalink / raw)
  To: linux-btrfs

Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald:
> Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald:
> > I get this:
> > 
> > merkaba:~> btrfs scrub status -d /
> > scrub status for […]
> > scrub device /dev/mapper/sata-debian (id 1) history
> > 
> >         scrub started at Thu Oct 22 10:05:49 2015 and was aborted after
> >         00:00:00
> >         total bytes scrubbed: 0.00B with 0 errors
> > 
> > scrub device /dev/dm-2 (id 2) history
> > 
> >         scrub started at Thu Oct 22 10:05:49 2015 and was aborted after
> >         00:01:30
> >         total bytes scrubbed: 23.81GiB with 0 errors
> > 
> > For / scrub aborts for sata SSD immediately.
> > 
> > For /home scrub aborts for both SSDs at some time.
> > 
> > merkaba:~> btrfs scrub status -d /home
> > scrub status for […]
> > scrub device /dev/mapper/msata-home (id 1) history
> > 
> >         scrub started at Thu Oct 22 10:09:37 2015 and was aborted after
> >         00:01:31
> >         total bytes scrubbed: 22.03GiB with 0 errors
> > 
> > scrub device /dev/dm-3 (id 2) history
> > 
> >         scrub started at Thu Oct 22 10:09:37 2015 and was aborted after
> >         00:03:34
> >         total bytes scrubbed: 53.30GiB with 0 errors
> > 
> > Also single volume BTRFS is affected:
> > 
> > merkaba:~> btrfs scrub status /daten
> > scrub status for […]
> > 
> >         scrub started at Thu Oct 22 10:36:38 2015 and was aborted after
> >         00:00:00
> >         total bytes scrubbed: 0.00B with 0 errors
> > 
> > No errors in dmesg, btrfs device stat or smartctl -a.
> > 
> > Any known issue?
> 
> I am still seeing this in 4.3-rc7. It happens so that on one SSD BTRFS
> doesn´t even start scrubbing. But in the end it aborts it scrubbing anyway.
> 
> I do not see any other issue so far. But I would really like to be able to
> scrub my BTRFS filesystems completely again. Any hints? Any further
> information needed?
> 
> merkaba:~> btrfs scrub status -d /
> scrub status for […]
> scrub device /dev/dm-5 (id 1) history
>         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
>         total bytes scrubbed: 0.00B with 0 errors
> scrub device /dev/mapper/msata-debian (id 2) status
>         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:20
>         total bytes scrubbed: 5.27GiB with 0 errors
> merkaba:~> btrfs scrub status -d /
> scrub status for […]
> scrub device /dev/dm-5 (id 1) history
>         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
>         total bytes scrubbed: 0.00B with 0 errors
> scrub device /dev/mapper/msata-debian (id 2) status
>         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:25
>         total bytes scrubbed: 6.59GiB with 0 errors
> merkaba:~> btrfs scrub status -d /
> scrub status for […]
> scrub device /dev/dm-5 (id 1) history
>         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
>         total bytes scrubbed: 0.00B with 0 errors
> scrub device /dev/mapper/msata-debian (id 2) status
>         scrub started at Sat Oct 31 11:58:45 2015, running for 00:01:25
>         total bytes scrubbed: 21.97GiB with 0 errors
> merkaba:~> btrfs scrub status -d /
> scrub status for […]
> scrub device /dev/dm-5 (id 1) history
>         scrub started at Sat Oct 31 11:58:45 2015 and was aborted after
> 00:00:00 total bytes scrubbed: 0.00B with 0 errors
> scrub device /dev/mapper/msata-debian (id 2) history
>         scrub started at Sat Oct 31 11:58:45 2015 and was aborted after
> 00:01:32 total bytes scrubbed: 23.63GiB with 0 errors
> 
> 
> For the sake of it I am going to btrfs check one of the filesystem where
> BTRFS aborts scrubbing (which is all of the laptop filesystems, not only
> the RAID 1 one).
> 
> I will use the /daten filesystem as I can unmount it during laptop runtime
> easily. There scrubbing aborts immediately:
> 
> merkaba:~> btrfs scrub start /daten
> scrub started on /daten, fsid […] (pid=13861)
> merkaba:~> btrfs scrub status /daten
> scrub status for […]
>         scrub started at Sat Oct 31 12:04:25 2015 and was aborted after
> 00:00:00 total bytes scrubbed: 0.00B with 0 errors
> 
> It is single device:
> 
> merkaba:~> btrfs fi sh /daten
> Label: 'daten'  uuid: […]
>         Total devices 1 FS bytes used 227.23GiB
>         devid    1 size 230.00GiB used 230.00GiB path
> /dev/mapper/msata-daten
> 
> btrfs-progs v4.2.2
> merkaba:~> btrfs fi df /daten
> Data, single: total=228.99GiB, used=226.79GiB
> System, single: total=4.00MiB, used=48.00KiB
> Metadata, single: total=1.01GiB, used=449.50MiB
> GlobalReserve, single: total=160.00MiB, used=0.00B
> 
> 
> I do not see any output in btrfs check that points to any issue:
> 
> merkaba:~> btrfs check /dev/msata/daten
> Checking filesystem on /dev/msata/daten
> UUID: 7918274f-e2ec-4983-bbb0-aa93ef95fcf7
> checking extents
> checking free space cache
> checking fs roots
> checking csums
> checking root refs
> found 243936530607 bytes used err is 0
> total csum bytes: 237758932
> total tree bytes: 471384064
> total fs tree bytes: 116473856
> total extent tree bytes: 78544896
> btree space waste bytes: 57523323
> file data blocks allocated: 422700576768
>  referenced 243803443200
> btrfs-progs v4.2.2

Even with 4.4-rc2 this issue still happens:

merkaba:~> btrfs scrub status -d /
scrub status for […]
scrub device /dev/mapper/sata-debian (id 1) history
        scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:00
        total bytes scrubbed: 0.00B with 0 errors
scrub device /dev/dm-2 (id 2) status
        scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:55
        total bytes scrubbed: 14.24GiB with 0 errors

merkaba:~> btrfs scrub status -d /
scrub status for […]
scrub device /dev/mapper/sata-debian (id 1) history
        scrub started at Wed Nov 25 16:28:33 2015 and was aborted after 
00:00:00
        total bytes scrubbed: 0.00B with 0 errors
scrub device /dev/dm-2 (id 2) history
        scrub started at Wed Nov 25 16:28:33 2015 and was aborted after 
00:01:33
        total bytes scrubbed: 23.71GiB with 0 errors

merkaba:~> cat /proc/version
Linux version 4.4.0-rc2-tp520+ (martin@merkaba) (gcc version 5.2.1 20151121 
(Debian 5.2.1-24) ) #45 SMP PREEMPT Mon Nov 23 17:10:16 CET 2015

This time I also removed all files in /var/lib/btrfs to avoid any possible 
issues with saved BTRFS status reports. (Yeah, I think it would have been 
enough to just delete the one for the filesystem with that UUID.)

As written this bug also happens with a single device BTRFS.


I´d report a bug report, in case anyone would be interested. But if the 
interest it like in this mailinglist post I can spare myself the time for 
reporting via bugzilla.

So does anyone at all care about this issue?

Thanks,
-- 
Martin

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.3-rc4] scrubbing aborts before finishing
  2015-11-25 15:35   ` Martin Steigerwald
@ 2015-11-26 16:39     ` Duncan
  2015-12-14  7:59     ` Martin Steigerwald
  1 sibling, 0 replies; 9+ messages in thread
From: Duncan @ 2015-11-26 16:39 UTC (permalink / raw)
  To: linux-btrfs

Martin Steigerwald posted on Wed, 25 Nov 2015 16:35:39 +0100 as excerpted:

> I´d report a bug report, in case anyone would be interested. But if the
> interest it like in this mailinglist post I can spare myself the time
> for reporting via bugzilla.
> 
> So does anyone at all care about this issue?

FWIW I'm interested, but haven't as a user seen the same thing here... 
scrubs have worked fine here unless I forget to sudo, in which case they 
don't work at all as they can't get necessary privs.

And I'm stumped as to what else it might be.  I don't even have an idea 
where to start looking for clues.

But not being a dev and having not the foggiest what the problem may be, 
it's not like my interest is going to help much, which is why I didn't 
reply earlier.  Just posting now to say you're not alone in your 
interest.  Things like this that don't seem to have any logic bother me, 
tho, so I really would like to at least learn why it's happening.

-- 
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] 9+ messages in thread

* Re: [4.3-rc4] scrubbing aborts before finishing
  2015-11-25 15:35   ` Martin Steigerwald
  2015-11-26 16:39     ` Duncan
@ 2015-12-14  7:59     ` Martin Steigerwald
  2015-12-14 17:31       ` Henk Slager
  2015-12-15 23:18       ` [4.3-rc4] scrubbing aborts before finishing (probably solved) Martin Steigerwald
  1 sibling, 2 replies; 9+ messages in thread
From: Martin Steigerwald @ 2015-12-14  7:59 UTC (permalink / raw)
  To: linux-btrfs

Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie:
> Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald:
> > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald:
> > > I get this:
> > > 
> > > merkaba:~> btrfs scrub status -d /
> > > scrub status for […]
> > > scrub device /dev/mapper/sata-debian (id 1) history
> > > 
> > >         scrub started at Thu Oct 22 10:05:49 2015 and was aborted after
> > >         00:00:00
> > >         total bytes scrubbed: 0.00B with 0 errors
> > > 
> > > scrub device /dev/dm-2 (id 2) history
> > > 
> > >         scrub started at Thu Oct 22 10:05:49 2015 and was aborted after
> > >         00:01:30
> > >         total bytes scrubbed: 23.81GiB with 0 errors
> > > 
> > > For / scrub aborts for sata SSD immediately.
> > > 
> > > For /home scrub aborts for both SSDs at some time.
> > > 
> > > merkaba:~> btrfs scrub status -d /home
> > > scrub status for […]
> > > scrub device /dev/mapper/msata-home (id 1) history
> > > 
> > >         scrub started at Thu Oct 22 10:09:37 2015 and was aborted after
> > >         00:01:31
> > >         total bytes scrubbed: 22.03GiB with 0 errors
> > > 
> > > scrub device /dev/dm-3 (id 2) history
> > > 
> > >         scrub started at Thu Oct 22 10:09:37 2015 and was aborted after
> > >         00:03:34
> > >         total bytes scrubbed: 53.30GiB with 0 errors
> > > 
> > > Also single volume BTRFS is affected:
> > > 
> > > merkaba:~> btrfs scrub status /daten
> > > scrub status for […]
> > > 
> > >         scrub started at Thu Oct 22 10:36:38 2015 and was aborted after
> > >         00:00:00
> > >         total bytes scrubbed: 0.00B with 0 errors
> > > 
> > > No errors in dmesg, btrfs device stat or smartctl -a.
> > > 
> > > Any known issue?
> > 
> > I am still seeing this in 4.3-rc7. It happens so that on one SSD BTRFS
> > doesn´t even start scrubbing. But in the end it aborts it scrubbing
> > anyway.
> > 
> > I do not see any other issue so far. But I would really like to be able to
> > scrub my BTRFS filesystems completely again. Any hints? Any further
> > information needed?
> > 
> > merkaba:~> btrfs scrub status -d /
> > scrub status for […]
> > scrub device /dev/dm-5 (id 1) history
> > 
> >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
> >         total bytes scrubbed: 0.00B with 0 errors
> > 
> > scrub device /dev/mapper/msata-debian (id 2) status
> > 
> >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:20
> >         total bytes scrubbed: 5.27GiB with 0 errors
> > 
> > merkaba:~> btrfs scrub status -d /
> > scrub status for […]
> > scrub device /dev/dm-5 (id 1) history
> > 
> >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
> >         total bytes scrubbed: 0.00B with 0 errors
> > 
> > scrub device /dev/mapper/msata-debian (id 2) status
> > 
> >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:25
> >         total bytes scrubbed: 6.59GiB with 0 errors
> > 
> > merkaba:~> btrfs scrub status -d /
> > scrub status for […]
> > scrub device /dev/dm-5 (id 1) history
> > 
> >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
> >         total bytes scrubbed: 0.00B with 0 errors
> > 
> > scrub device /dev/mapper/msata-debian (id 2) status
> > 
> >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:01:25
> >         total bytes scrubbed: 21.97GiB with 0 errors
> > 
> > merkaba:~> btrfs scrub status -d /
> > scrub status for […]
> > scrub device /dev/dm-5 (id 1) history
> > 
> >         scrub started at Sat Oct 31 11:58:45 2015 and was aborted after
> > 
> > 00:00:00 total bytes scrubbed: 0.00B with 0 errors
> > scrub device /dev/mapper/msata-debian (id 2) history
> > 
> >         scrub started at Sat Oct 31 11:58:45 2015 and was aborted after
> > 
> > 00:01:32 total bytes scrubbed: 23.63GiB with 0 errors
> > 
> > 
> > For the sake of it I am going to btrfs check one of the filesystem where
> > BTRFS aborts scrubbing (which is all of the laptop filesystems, not only
> > the RAID 1 one).
> > 
> > I will use the /daten filesystem as I can unmount it during laptop runtime
> > easily. There scrubbing aborts immediately:
> > 
> > merkaba:~> btrfs scrub start /daten
> > scrub started on /daten, fsid […] (pid=13861)
> > merkaba:~> btrfs scrub status /daten
> > scrub status for […]
> > 
> >         scrub started at Sat Oct 31 12:04:25 2015 and was aborted after
> > 
> > 00:00:00 total bytes scrubbed: 0.00B with 0 errors
> > 
> > It is single device:
> > 
> > merkaba:~> btrfs fi sh /daten
> > Label: 'daten'  uuid: […]
> > 
> >         Total devices 1 FS bytes used 227.23GiB
> >         devid    1 size 230.00GiB used 230.00GiB path
> > 
> > /dev/mapper/msata-daten
> > 
> > btrfs-progs v4.2.2
> > merkaba:~> btrfs fi df /daten
> > Data, single: total=228.99GiB, used=226.79GiB
> > System, single: total=4.00MiB, used=48.00KiB
> > Metadata, single: total=1.01GiB, used=449.50MiB
> > GlobalReserve, single: total=160.00MiB, used=0.00B
> > 
> > 
> > I do not see any output in btrfs check that points to any issue:
> > 
> > merkaba:~> btrfs check /dev/msata/daten
> > Checking filesystem on /dev/msata/daten
> > UUID: 7918274f-e2ec-4983-bbb0-aa93ef95fcf7
> > checking extents
> > checking free space cache
> > checking fs roots
> > checking csums
> > checking root refs
> > found 243936530607 bytes used err is 0
> > total csum bytes: 237758932
> > total tree bytes: 471384064
> > total fs tree bytes: 116473856
> > total extent tree bytes: 78544896
> > btree space waste bytes: 57523323
> > file data blocks allocated: 422700576768
> > 
> >  referenced 243803443200
> > 
> > btrfs-progs v4.2.2
> 
> Even with 4.4-rc2 this issue still happens:
> 
> merkaba:~> btrfs scrub status -d /
> scrub status for […]
> scrub device /dev/mapper/sata-debian (id 1) history
>         scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:00
>         total bytes scrubbed: 0.00B with 0 errors
> scrub device /dev/dm-2 (id 2) status
>         scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:55
>         total bytes scrubbed: 14.24GiB with 0 errors
> 
> merkaba:~> btrfs scrub status -d /
> scrub status for […]
> scrub device /dev/mapper/sata-debian (id 1) history
>         scrub started at Wed Nov 25 16:28:33 2015 and was aborted after
> 00:00:00
>         total bytes scrubbed: 0.00B with 0 errors
> scrub device /dev/dm-2 (id 2) history
>         scrub started at Wed Nov 25 16:28:33 2015 and was aborted after
> 00:01:33
>         total bytes scrubbed: 23.71GiB with 0 errors
> 
> merkaba:~> cat /proc/version
> Linux version 4.4.0-rc2-tp520+ (martin@merkaba) (gcc version 5.2.1 20151121
> (Debian 5.2.1-24) ) #45 SMP PREEMPT Mon Nov 23 17:10:16 CET 2015
> 
> This time I also removed all files in /var/lib/btrfs to avoid any possible
> issues with saved BTRFS status reports. (Yeah, I think it would have been
> enough to just delete the one for the filesystem with that UUID.)
> 
> As written this bug also happens with a single device BTRFS.
> 
> 
> I´d report a bug report, in case anyone would be interested. But if the
> interest it like in this mailinglist post I can spare myself the time for
> reporting via bugzilla.
> 
> So does anyone at all care about this issue?

I am replying to this a fourth time in the hope that someone can at least give 
some suggestion on how to move forward with this.

Thanks,
-- 
Martin

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.3-rc4] scrubbing aborts before finishing
  2015-12-14  7:59     ` Martin Steigerwald
@ 2015-12-14 17:31       ` Henk Slager
  2015-12-14 18:11         ` Henk Slager
  2015-12-15 23:18       ` [4.3-rc4] scrubbing aborts before finishing (probably solved) Martin Steigerwald
  1 sibling, 1 reply; 9+ messages in thread
From: Henk Slager @ 2015-12-14 17:31 UTC (permalink / raw)
  To: linux-btrfs

[...]
>> > merkaba:~> btrfs fi sh /daten
>> > Label: 'daten'  uuid: […]
>> >
>> >         Total devices 1 FS bytes used 227.23GiB
>> >         devid    1 size 230.00GiB used 230.00GiB path
[...]
>> > merkaba:~> btrfs fi df /daten
>> > Data, single: total=228.99GiB, used=226.79GiB
>> > System, single: total=4.00MiB, used=48.00KiB
>> > Metadata, single: total=1.01GiB, used=449.50MiB
>> > GlobalReserve, single: total=160.00MiB, used=0.00B

If this is still the fill-level of the storage device, then also with
4.4-rcX and new enough tools it will fail I think.
AFAIK, scrub does writes (in metadata?) so I think a non-read-only
scrub command can't allocate space. See all other comments/threads
w.r.t. allocated / free space.
Especially an fs of this size, I would keep ~10% free on
'device-level' ( 227.23GiB would need to be 207.00GiB ) and also ~10%
on 'chunk-level' ( 226.79GiB would need to be 186.30GiB ).

Assuming you don't have snapshots, a   btrfs fi defrag -r /daten
might give some more room short-term, after you just (re)moved files
off the fs first.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.3-rc4] scrubbing aborts before finishing
  2015-12-14 17:31       ` Henk Slager
@ 2015-12-14 18:11         ` Henk Slager
  0 siblings, 0 replies; 9+ messages in thread
From: Henk Slager @ 2015-12-14 18:11 UTC (permalink / raw)
  To: linux-btrfs

On Mon, Dec 14, 2015 at 6:31 PM, Henk Slager <eye1tm@gmail.com> wrote:
> [...]
>>> > merkaba:~> btrfs fi sh /daten
>>> > Label: 'daten'  uuid: […]
>>> >
>>> >         Total devices 1 FS bytes used 227.23GiB
>>> >         devid    1 size 230.00GiB used 230.00GiB path
> [...]
>>> > merkaba:~> btrfs fi df /daten
>>> > Data, single: total=228.99GiB, used=226.79GiB
>>> > System, single: total=4.00MiB, used=48.00KiB
>>> > Metadata, single: total=1.01GiB, used=449.50MiB
>>> > GlobalReserve, single: total=160.00MiB, used=0.00B
>
> If this is still the fill-level of the storage device, then also with
> 4.4-rcX and new enough tools it will fail I think.
> AFAIK, scrub does writes (in metadata?) so I think a non-read-only
> scrub command can't allocate space. See all other comments/threads
> w.r.t. allocated / free space.
> Especially an fs of this size, I would keep ~10% free on
> 'device-level' ( 227.23GiB would need to be 207.00GiB ) and also ~10%
> on 'chunk-level' ( 226.79GiB would need to be 186.30GiB ).
>
> Assuming you don't have snapshots, a   btrfs fi defrag -r /daten
> might give some more room short-term, after you just (re)moved files
> off the fs first.
# btrfs fi defrag -r -clzo /daten
I meant.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.3-rc4] scrubbing aborts before finishing (probably solved)
  2015-12-14  7:59     ` Martin Steigerwald
  2015-12-14 17:31       ` Henk Slager
@ 2015-12-15 23:18       ` Martin Steigerwald
  2015-12-17 13:29         ` [4.3-rc4] scrubbing aborts before finishing (SOLVED) Martin Steigerwald
  1 sibling, 1 reply; 9+ messages in thread
From: Martin Steigerwald @ 2015-12-15 23:18 UTC (permalink / raw)
  To: linux-btrfs

Am Montag, 14. Dezember 2015, 08:59:59 CET schrieb Martin Steigerwald:
> Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie:
> > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald:
> > > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin 
Steigerwald:
> > > > I get this:
> > > > 
> > > > merkaba:~> btrfs scrub status -d /
> > > > scrub status for […]
> > > > scrub device /dev/mapper/sata-debian (id 1) history
> > > > 
> > > >         scrub started at Thu Oct 22 10:05:49 2015 and was aborted
> > > >         after
> > > >         00:00:00
> > > >         total bytes scrubbed: 0.00B with 0 errors
> > > > 
> > > > scrub device /dev/dm-2 (id 2) history
> > > > 
> > > >         scrub started at Thu Oct 22 10:05:49 2015 and was aborted
> > > >         after
> > > >         00:01:30
> > > >         total bytes scrubbed: 23.81GiB with 0 errors
> > > > 
> > > > For / scrub aborts for sata SSD immediately.
> > > > 
> > > > For /home scrub aborts for both SSDs at some time.
> > > > 
> > > > merkaba:~> btrfs scrub status -d /home
> > > > scrub status for […]
> > > > scrub device /dev/mapper/msata-home (id 1) history
> > > > 
> > > >         scrub started at Thu Oct 22 10:09:37 2015 and was aborted
> > > >         after
> > > >         00:01:31
> > > >         total bytes scrubbed: 22.03GiB with 0 errors
> > > > 
> > > > scrub device /dev/dm-3 (id 2) history
> > > > 
> > > >         scrub started at Thu Oct 22 10:09:37 2015 and was aborted
> > > >         after
> > > >         00:03:34
> > > >         total bytes scrubbed: 53.30GiB with 0 errors
> > > > 
> > > > Also single volume BTRFS is affected:
> > > > 
> > > > merkaba:~> btrfs scrub status /daten
> > > > scrub status for […]
> > > > 
> > > >         scrub started at Thu Oct 22 10:36:38 2015 and was aborted
> > > >         after
> > > >         00:00:00
> > > >         total bytes scrubbed: 0.00B with 0 errors
> > > > 
> > > > No errors in dmesg, btrfs device stat or smartctl -a.
> > > > 
> > > > Any known issue?
> > > 
> > > I am still seeing this in 4.3-rc7. It happens so that on one SSD BTRFS
> > > doesn´t even start scrubbing. But in the end it aborts it scrubbing
> > > anyway.
> > > 
> > > I do not see any other issue so far. But I would really like to be able
> > > to
> > > scrub my BTRFS filesystems completely again. Any hints? Any further
> > > information needed?
> > > 
> > > merkaba:~> btrfs scrub status -d /
> > > scrub status for […]
> > > scrub device /dev/dm-5 (id 1) history
> > > 
> > >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
> > >         total bytes scrubbed: 0.00B with 0 errors
> > > 
> > > scrub device /dev/mapper/msata-debian (id 2) status
> > > 
> > >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:20
> > >         total bytes scrubbed: 5.27GiB with 0 errors
> > > 
> > > merkaba:~> btrfs scrub status -d /
> > > scrub status for […]
> > > scrub device /dev/dm-5 (id 1) history
> > > 
> > >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
> > >         total bytes scrubbed: 0.00B with 0 errors
> > > 
> > > scrub device /dev/mapper/msata-debian (id 2) status
> > > 
> > >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:25
> > >         total bytes scrubbed: 6.59GiB with 0 errors
> > > 
> > > merkaba:~> btrfs scrub status -d /
> > > scrub status for […]
> > > scrub device /dev/dm-5 (id 1) history
> > > 
> > >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:00:00
> > >         total bytes scrubbed: 0.00B with 0 errors
> > > 
> > > scrub device /dev/mapper/msata-debian (id 2) status
> > > 
> > >         scrub started at Sat Oct 31 11:58:45 2015, running for 00:01:25
> > >         total bytes scrubbed: 21.97GiB with 0 errors
> > > 
> > > merkaba:~> btrfs scrub status -d /
> > > scrub status for […]
> > > scrub device /dev/dm-5 (id 1) history
> > > 
> > >         scrub started at Sat Oct 31 11:58:45 2015 and was aborted after
> > > 
> > > 00:00:00 total bytes scrubbed: 0.00B with 0 errors
> > > scrub device /dev/mapper/msata-debian (id 2) history
> > > 
> > >         scrub started at Sat Oct 31 11:58:45 2015 and was aborted after
> > > 
> > > 00:01:32 total bytes scrubbed: 23.63GiB with 0 errors
> > > 
> > > 
> > > For the sake of it I am going to btrfs check one of the filesystem where
> > > BTRFS aborts scrubbing (which is all of the laptop filesystems, not only
> > > the RAID 1 one).
> > > 
> > > I will use the /daten filesystem as I can unmount it during laptop
> > > runtime
> > > easily. There scrubbing aborts immediately:
> > > 
> > > merkaba:~> btrfs scrub start /daten
> > > scrub started on /daten, fsid […] (pid=13861)
> > > merkaba:~> btrfs scrub status /daten
> > > scrub status for […]
> > > 
> > >         scrub started at Sat Oct 31 12:04:25 2015 and was aborted after
> > > 
> > > 00:00:00 total bytes scrubbed: 0.00B with 0 errors
> > > 
> > > It is single device:
> > > 
> > > merkaba:~> btrfs fi sh /daten
> > > Label: 'daten'  uuid: […]
> > > 
> > >         Total devices 1 FS bytes used 227.23GiB
> > >         devid    1 size 230.00GiB used 230.00GiB path
> > > 
> > > /dev/mapper/msata-daten
> > > 
> > > btrfs-progs v4.2.2
> > > merkaba:~> btrfs fi df /daten
> > > Data, single: total=228.99GiB, used=226.79GiB
> > > System, single: total=4.00MiB, used=48.00KiB
> > > Metadata, single: total=1.01GiB, used=449.50MiB
> > > GlobalReserve, single: total=160.00MiB, used=0.00B
> > > 
> > > 
> > > I do not see any output in btrfs check that points to any issue:
> > > 
> > > merkaba:~> btrfs check /dev/msata/daten
> > > Checking filesystem on /dev/msata/daten
> > > UUID: 7918274f-e2ec-4983-bbb0-aa93ef95fcf7
> > > checking extents
> > > checking free space cache
> > > checking fs roots
> > > checking csums
> > > checking root refs
> > > found 243936530607 bytes used err is 0
> > > total csum bytes: 237758932
> > > total tree bytes: 471384064
> > > total fs tree bytes: 116473856
> > > total extent tree bytes: 78544896
> > > btree space waste bytes: 57523323
> > > file data blocks allocated: 422700576768
> > > 
> > >  referenced 243803443200
> > > 
> > > btrfs-progs v4.2.2
> > 
> > Even with 4.4-rc2 this issue still happens:
> > 
> > merkaba:~> btrfs scrub status -d /
> > scrub status for […]
> > scrub device /dev/mapper/sata-debian (id 1) history
> > 
> >         scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:00
> >         total bytes scrubbed: 0.00B with 0 errors
> > 
> > scrub device /dev/dm-2 (id 2) status
> > 
> >         scrub started at Wed Nov 25 16:28:33 2015, running for 00:00:55
> >         total bytes scrubbed: 14.24GiB with 0 errors
> > 
> > merkaba:~> btrfs scrub status -d /
> > scrub status for […]
> > scrub device /dev/mapper/sata-debian (id 1) history
> > 
> >         scrub started at Wed Nov 25 16:28:33 2015 and was aborted after
> > 
> > 00:00:00
> > 
> >         total bytes scrubbed: 0.00B with 0 errors
> > 
> > scrub device /dev/dm-2 (id 2) history
> > 
> >         scrub started at Wed Nov 25 16:28:33 2015 and was aborted after
> > 
> > 00:01:33
> > 
> >         total bytes scrubbed: 23.71GiB with 0 errors
> > 
> > merkaba:~> cat /proc/version
> > Linux version 4.4.0-rc2-tp520+ (martin@merkaba) (gcc version 5.2.1
> > 20151121
> > (Debian 5.2.1-24) ) #45 SMP PREEMPT Mon Nov 23 17:10:16 CET 2015
> > 
> > This time I also removed all files in /var/lib/btrfs to avoid any possible
> > issues with saved BTRFS status reports. (Yeah, I think it would have been
> > enough to just delete the one for the filesystem with that UUID.)
> > 
> > As written this bug also happens with a single device BTRFS.
> > 
> > 
> > I´d report a bug report, in case anyone would be interested. But if the
> > interest it like in this mailinglist post I can spare myself the time for
> > reporting via bugzilla.
> > 
> > So does anyone at all care about this issue?
> 
> I am replying to this a fourth time in the hope that someone can at least
> give some suggestion on how to move forward with this.

It was a third time, and well:

I now have 4.4-rc5 running, the boot crash I had appears to be fixed. Oh, and 
I see that scrubbing / at leasted worked now:

merkaba:~> btrfs scrub status -d /
scrub status for […]
scrub device /dev/dm-5 (id 1) history
        scrub started at Wed Dec 16 00:13:20 2015 and finished after 00:01:42
        total bytes scrubbed: 23.94GiB with 0 errors
scrub device /dev/mapper/msata-debian (id 2) history
        scrub started at Wed Dec 16 00:13:20 2015 and finished after 00:01:34
        total bytes scrubbed: 23.94GiB with 0 errors

I will check with other BTRFS filesystems tomorrow and report back whether 
scrubbing is stable for meagain.

Ciao,
-- 
Martin

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [4.3-rc4] scrubbing aborts before finishing (SOLVED)
  2015-12-15 23:18       ` [4.3-rc4] scrubbing aborts before finishing (probably solved) Martin Steigerwald
@ 2015-12-17 13:29         ` Martin Steigerwald
  0 siblings, 0 replies; 9+ messages in thread
From: Martin Steigerwald @ 2015-12-17 13:29 UTC (permalink / raw)
  To: linux-btrfs

Am Mittwoch, 16. Dezember 2015, 00:18:53 CET schrieb Martin Steigerwald:
> Am Montag, 14. Dezember 2015, 08:59:59 CET schrieb Martin Steigerwald:
> > Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie:
> > > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald:
> > > > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin
> Steigerwald:
> > > > > I get this:
> > > > > 
> > > > > merkaba:~> btrfs scrub status -d /
> > > > > scrub status for […]
> > > > > scrub device /dev/mapper/sata-debian (id 1) history
> > > > > 
> > > > >         scrub started at Thu Oct 22 10:05:49 2015 and was aborted
> > > > >         after
> > > > >         00:00:00
> > > > >         total bytes scrubbed: 0.00B with 0 errors
> > > > > 
> > > > > scrub device /dev/dm-2 (id 2) history
> > > > > 
> > > > >         scrub started at Thu Oct 22 10:05:49 2015 and was aborted
> > > > >         after
> > > > >         00:01:30
> > > > >         total bytes scrubbed: 23.81GiB with 0 errors
> > > > > 
> > > > > For / scrub aborts for sata SSD immediately.
> > > > > 
> > > > > For /home scrub aborts for both SSDs at some time.
[…]
> I now have 4.4-rc5 running, the boot crash I had appears to be fixed. Oh,
> and I see that scrubbing / at leasted worked now:
> 
> merkaba:~> btrfs scrub status -d /
> scrub status for […]
> scrub device /dev/dm-5 (id 1) history
>         scrub started at Wed Dec 16 00:13:20 2015 and finished after
> 00:01:42 total bytes scrubbed: 23.94GiB with 0 errors
> scrub device /dev/mapper/msata-debian (id 2) history
>         scrub started at Wed Dec 16 00:13:20 2015 and finished after
> 00:01:34 total bytes scrubbed: 23.94GiB with 0 errors
> 
> I will check with other BTRFS filesystems tomorrow and report back whether
> scrubbing is stable for meagain.

This appears to be fixed with 4.4-rc5. Thank you!!!

Thanks,
-- 
Martin

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-12-17 13:29 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-22  8:41 [4.3-rc4] scrubbing aborts before finishing Martin Steigerwald
2015-10-31 11:10 ` Martin Steigerwald
2015-11-25 15:35   ` Martin Steigerwald
2015-11-26 16:39     ` Duncan
2015-12-14  7:59     ` Martin Steigerwald
2015-12-14 17:31       ` Henk Slager
2015-12-14 18:11         ` Henk Slager
2015-12-15 23:18       ` [4.3-rc4] scrubbing aborts before finishing (probably solved) Martin Steigerwald
2015-12-17 13:29         ` [4.3-rc4] scrubbing aborts before finishing (SOLVED) Martin Steigerwald

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).