Re: [PATCH] btrfs: Fix no space bug caused by removing bg

From: Hugo Mills <hugo@carfax.org.uk>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: dsterba@suse.cz,
	"Holger Hoffstätte" <holger.hoffstaette@googlemail.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: Fix no space bug caused by removing bg
Date: Wed, 23 Sep 2015 13:45:35 +0000	[thread overview]
Message-ID: <20150923134535.GN5918@carfax.org.uk> (raw)
In-Reply-To: <5602A6EA.8050107@gmx.com>

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

On Wed, Sep 23, 2015 at 09:19:38PM +0800, Qu Wenruo wrote:
> 在 2015年09月23日 21:12, David Sterba 写道:
> >On Tue, Sep 22, 2015 at 02:36:02PM +0000, Hugo Mills wrote:
> >>>Yeah, right now there's no persistent default for the allocator. I'm
> >>>still hoping that the object properties will magically solve that.
> >>
> >>    There's no obvious place that filesystem-wide properties can be
> >>stored, though. There's a userspace tool to manipulate the few current
> >>FS-wide properties, but that's all special-cased to use the
> >>"historical" ioctls for those properties, with no generalisation of a
> >>property store, or even (IIRC) any external API for them.
> >
> > From the UI point, we proposed to add a specifier that would route the
> >property to either subvolume or the filesystem:
> >
> >$ btrfs prop set -t filesystem bgtype raid0
> >$ btrfs prop set -t subvolume bgtype raid1
> >
> 
> BTW, is btrfs going to support different chunk/bg type for subvolume?!
> I thought data/meta/system chunk types are all per filesystem level,
> and was planning to use superblock to record it...

   Well, it's been talked about for a *long* time, and it's certainly
something for which there's use-cases, and non-zero demand from users.

> If really to support that, does it mean we will have different
> meta/data type for each subvolume?
> That's a little too flex for me....

   I think you'd have to have a single metadata type for the whole FS
-- it doesn't make much sense to try splitting that up "by subvolume",
as almost all of the data structures are common to all subvolumes. For
data, however, it should certainly be possible to specify that a
subvol's data be stored with a given replication policy.

   While David and Austin's suggestion of a special xattr on the top
level subvol for the FS default is one possible implementation, using
the superblock would work just as well -- with the minor detail that
you'd have to special-case it into the properties UI, whereas using
xattrs, there will be less special-casing involved.

   Hugo.

> Thanks,
> Qu
> 
> >How this will get stored in the xattrs is another question. As there's
> >always only single instance of the filesystem properties, it coud be
> >something like 'btrfs.fs.bgtype' and be stored as a xattr of the
> >toplevel subvolume.

-- 
Hugo Mills             | 2 + 2 = 5, for sufficiently large values of 2.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]