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

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

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

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).



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]