On 2015-09-23 09:19, Qu Wenruo wrote:
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).在 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 raid1BTW, 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....
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
