All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: [4.3-rc4] scrubbing aborts before finishing
Date: Wed, 25 Nov 2015 16:35:39 +0100	[thread overview]
Message-ID: <4738187.k1WenrURk2@merkaba> (raw)
In-Reply-To: <1475910.a5YfPuWqAN@merkaba>

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

  reply	other threads:[~2015-11-25 15:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4738187.k1WenrURk2@merkaba \
    --to=martin@lichtvoll.de \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.