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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





在 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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux