All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.