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

From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: 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 09:57:47 -0400	[thread overview]
Message-ID: <5602AFDB.6030002@gmail.com> (raw)
In-Reply-To: <20150923132829.GB12815@twin.jikos.cz>

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

On 2015-09-23 09:28, David Sterba wrote:
> On Tue, Sep 22, 2015 at 03:39:30PM +0000, Hugo Mills wrote:
>>> The way I would expect things to work is that a new subvolume
>>> inherits it's properties from it's parent (if it's a snapshot),
>>
>>     Definitely this.
>>
>>> or
>>> from the next higher subvolume it's nested in.
>>
>>     I don't think I like this. I'm not quite sure why, though, at the
>> moment.
>
> I don't like inheritance from other than the parent subvolume because
> this makes things less obvious.
Possibly, but that depends on how you view things.  Internally, 
subvolumes are independent of each other, but to a regular user (or 
anything that just uses the VFS layer), they look hierarchical, and as 
such without knowing the internals of the FS (which no regular user 
should need to know) I would expect the profile to propagate down from 
the (apparently) next higher subvolume.

It's worth noting that I mean that it should just copy the properties 
from the next higher subvolume at creation, and if the next higher 
subvolume doesn't have the properties set, then just use the filesystem 
defaults (and don't try to walk back up more than one level).
>>     It definitely makes the process at the start of allocating a new
>> block group much more complex: you have to walk back up through an
>> arbitrary depth of nested subvols to find the one that's actually got
>> a replication policy record in it. (Because after this feature is
>> brought in, there will be lots of filesystems without per-subvol
>> replication policies in them, and we have to have some way of dealing
>> with those as well).
>>
>>     With an FS default policy, you only need check the current subvol,
>> and then fall back to the FS default if that's not found.
>
> That looks reasonable to me.
>
>>     These things are, I think, likely to be lightly used: I would be
>> reasonably surprised to find more than two or possibly three storage
>> policies in use on any given system with a sane sysadmin.
>
> Agreed. At the moment I'm thinking about all the configuration
> possibilites we want to give to the users. Eg. the inheritance can be
> configurable on the property level.
>
> The usecase: the toplevel has compression enabled but I don't want any
> new subvolume share this property automatically.
>
> (The blockgroup type is probably a bad example for configurable
> inheritance as it would not work for shared extents if the type is
> different.)
Ideal situation in my opinion WRT block-group profile inheritance would 
be that when an extent becomes shared, it get's re-striped at the 
highest raid profile (prioritizing 3-copy or higher replication over 
raid56) of any of the files that share the extent.  This would result in 
some more I/O than the usual clone operation in some cases, but any 
other method has the potential to silently reduce the degree of data 
safety for a given file.


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