linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: "Stéphane Lesimple" <stephane_btrfs@lesimple.fr>,
	linux-btrfs@vger.kernel.org
Subject: Re: kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance
Date: Thu, 17 Sep 2015 11:03:54 +0800	[thread overview]
Message-ID: <55FA2D9A.1060405@cn.fujitsu.com> (raw)
In-Reply-To: <d2f30d85fa83b8b98af3c7e5a862044d@all.all>



Stéphane Lesimple wrote on 2015/09/16 22:41 +0200:
> Le 2015-09-16 22:18, Duncan a écrit :
>> Stéphane Lesimple posted on Wed, 16 Sep 2015 15:04:20 +0200 as excerpted:
>>
>>> Le 2015-09-16 12:46, Holger Hoffstätte a écrit :
>>>>
>>> I also disabled quota because it has almost for sure nothing to
>>> do with the bug, and now btrsfck is 100% happy:
>>
>> Yes.  Quotas have been a continuing issue on btrfs.  AFAIK, they're on
>> the third rewrite now, and still have some bugs to work out.  So what
>> I've been recommending is unless you're (a) directly and specifically
>> working with the devs to find and fix the quota issues (in which case
>> please keep at it! =:^), either you (b) really depend on quotas working
>> and btrfs isn't appropriate for you at this time, since they're known to
>> be buggy, so use a more mature filesystem where they're known to work, or
>> (c) you don't actually need quotas at all, so disable them and remove the
>> quota tracking metadata, thus avoiding the bugs in the feature entirely.
>> =:^)
>
> Well actually it's the (d) option ;)
> I activate the quota feature for only one reason : being able to track
> down how much space my snapshots are taking.
> I've been using ZFS in the past, and I was really missing the "zfs list"
> command that is able to tell you how much space a given snapshot is
> actually taking under btrfs.
> With quota enabled, I was able to somehow mimic zfs list with a perl
> script I wrote, btrfs-list :
>
> PATH                                    ID     TYPE     REFER      USED
> 'tank'                                  -1       df         -     2.66T
> (13.26G free)
>     /tank                                 5      vol    48.00K    48.00K
>     media                              1906   subvol     1.04T     1.04T
>     photos                             1909   subvol   116.37G   116.37G
>     main                               1911   subvol   973.23G   973.23G
>     bkp-slash                          3270   subvol    15.86G    15.86G
>     bkp-quasar                         3314   subvol    18.26G    16.00K
>        .snaps/bkp-quasar@2015-01-17    3317   rosnap    17.77G    40.76M
>        .snaps/bkp-quasar@2015-03-06    3318   rosnap    17.89G    88.88M
>        .snaps/bkp-quasar@2015-04-05    3319   rosnap    17.92G    90.97M
>        .snaps/bkp-quasar@2015-05-31    3320   rosnap    17.95G     1.02M
>        .snaps/bkp-quasar@2015-06-13    3321   rosnap    17.95G   760.00K
>        .snaps/bkp-quasar@2015-07-26    3322   rosnap    18.19G    17.88M
>        .snaps/bkp-quasar@2015-07-31    3323   rosnap    18.19G    14.58M
>        .snaps/bkp-quasar@2015-08-03    3324   rosnap    18.19G    17.43M
>     bkp-liznodisk                      3341   subvol     7.01G    16.00K
>        .snaps/bkp-liznodisk@2015-03-01 3342   rosnap     6.96G    75.37M
>        .snaps/bkp-liznodisk@2015-03-28 3343   rosnap     6.98G    84.93M
>        .snaps/bkp-liznodisk@2015-04-26 3344   rosnap     6.96G    67.14M
>        .snaps/bkp-liznodisk@2015-05-24 3345   rosnap     6.95G    47.67M
>        .snaps/bkp-liznodisk@2015-06-27 3346   rosnap     6.96G    67.97M
>        .snaps/bkp-liznodisk@2015-07-25 3347   rosnap     6.98G    60.30M
>        .snaps/bkp-liznodisk@2015-08-16 3348   rosnap     7.10G   159.44M
>     bkp-skyline                        3367   subvol    22.52G    22.52G
>
> I just pushed it to https://github.com/speed47/btrfs-list, if anybody is
> interested.
>
> Anyway, balance is running again for 7+ hours, trying to reproduce the
> bug twice, but no crash yet ... should happen soon now !
>
Yeah, that's completely one of the ideal use case of btrfs qgroup.

But I'm quite curious about the btrfsck error report on qgroup.

If btrfsck report such error, it means either I'm too confident about 
the recent qgroup accounting rework, or btrfsck has some bug which I 
didn't take much consideration during the kernel rework.

Would you please provide the full result of previous btrfsck with qgroup 
error?

Thanks,
Qu

  reply	other threads:[~2015-09-17  3:04 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-14 11:46 kernel BUG at linux-4.2.0/fs/btrfs/extent-tree.c:1833 on rebalance Stéphane Lesimple
2015-09-15 14:47 ` Stéphane Lesimple
2015-09-15 14:56   ` Josef Bacik
2015-09-15 21:47     ` Stéphane Lesimple
2015-09-16  5:02       ` Duncan
2015-09-16 10:28         ` Stéphane Lesimple
2015-09-16 10:46           ` Holger Hoffstätte
2015-09-16 13:04             ` Stéphane Lesimple
2015-09-16 20:18               ` Duncan
2015-09-16 20:41                 ` Stéphane Lesimple
2015-09-17  3:03                   ` Qu Wenruo [this message]
2015-09-17  6:11                     ` Stéphane Lesimple
2015-09-17  6:42                       ` Qu Wenruo
2015-09-17  8:02                         ` Stéphane Lesimple
2015-09-17  8:11                           ` Qu Wenruo
2015-09-17 10:08                             ` Stéphane Lesimple
2015-09-17 10:41                               ` Qu Wenruo
2015-09-17 18:47                                 ` Stéphane Lesimple
2015-09-18  0:59                                   ` Qu Wenruo
2015-09-18  7:36                                     ` Stéphane Lesimple
2015-09-18 10:15                                       ` Stéphane Lesimple
2015-09-18 10:26                                         ` Stéphane Lesimple
2015-09-20  1:22                                           ` Qu Wenruo
2015-09-20 10:35                                             ` Stéphane Lesimple
2015-09-20 10:51                                               ` Qu Wenruo
2015-09-20 11:14                                                 ` Stéphane Lesimple
2015-09-22  1:30                                                   ` Stéphane Lesimple
2015-09-22  1:37                                                     ` Qu Wenruo
2015-09-22  7:34                                                       ` Stéphane Lesimple
2015-09-22  8:40                                                         ` Qu Wenruo
2015-09-22  8:51                                                           ` Qu Wenruo
2015-09-22 14:31                                                             ` Stéphane Lesimple
2015-09-23  7:03                                                               ` Qu Wenruo
2015-09-23  9:40                                                                 ` Stéphane Lesimple
2015-09-23 10:13                                                                   ` Qu Wenruo
2015-09-17  6:29               ` Stéphane Lesimple
2015-09-17  7:54                 ` Stéphane Lesimple

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=55FA2D9A.1060405@cn.fujitsu.com \
    --to=quwenruo@cn.fujitsu.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=stephane_btrfs@lesimple.fr \
    /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 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).