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

From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: "Austin S Hemmelgarn" <ahferroin7@gmail.com>,
	dsterba@suse.cz, "Hugo Mills" <hugo@carfax.org.uk>,
	"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 22:00:12 +0800	[thread overview]
Message-ID: <5602B06C.8020600@gmx.com> (raw)
In-Reply-To: <5602A9F8.80802@gmail.com>

在 2015年09月23日 21:32, Austin S Hemmelgarn 写道:
> On 2015-09-23 09:19, 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...
>>
>> 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....
>>
> This has actually been a planned feature for a while, and really is
> needed to compete with the flexibility that ZFS gives for this kind of
> thing.  System chunk types should still be set separately (although,
> once we have n-way replication, they really should be set separately
> from metadata to at least one copy per device in multi-device filesystems).
>
>

Thanks, David and Austin.

As it's already planned, and I think it will need new incompact flag 
anyway, or old kernel can easily remove/convert desired profile.
So what about adding new ROOT_ITEM members to record data/meta profile?

I'm not a big fan to use xattr and it's quite easy to modify from user 
space, and not completely confident with the possible concurrency about 
xattr modification with chunk allocation.

And from the logical level, xattr is at the same level as inode, but 
subvolume is definitely at a higher level, even it's normally treated as 
directory.
So for me, I'd like to record it into root_item, not as sub xattr, even 
it may need an extra ioctl to handle it.

Anyway, I'm just a new comer for this feature, it's completely OK to 
ignore my stupid ideas.

BTW, what about the original patch? I hope it can be merged in next RC 
as the affected test case is quite a lot...

Thanks,
Qu