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

[Austin S Hemmelgarn]

On 2015-09-22 10:36, Hugo Mills wrote:

On Tue, Sep 22, 2015 at 04:23:33PM +0200, David Sterba wrote:

On Tue, Sep 22, 2015 at 01:41:31PM +0000, Hugo Mills wrote:

On Tue, Sep 22, 2015 at 03:36:43PM +0200, Holger Hoffstätte wrote:

On 09/22/15 14:59, Jeff Mahoney wrote:
(snip)

So if they way we want to prevent the loss of raid type info is by
maintaining the last block group allocated with that raid type, fine,
but that's a separate discussion.  Personally, I think keeping 1GB

At this point I'm much more surprised to learn that the RAID type can
apparently get "lost" in the first place, and is not persisted
separately. I mean..wat?

    It's always been like that, unfortunately.

    The code tries to use the RAID type that's already present to work
out what the next allocation should be. If there aren't any chunks in
the FS, the configuration is lost, because it's not stored anywhere
else. It's one of the things that tripped me up badly when I was
failing to rewrite the chunk allocator last year.

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.

    We're nominally using xattrs in the btrfs: namespace on directories
and files, and presumably on the top directory of a subvolume for
subvol-wide properties, but it's not clear where the FS-wide values
should go: in the top directory of subvolid=5 would be confusing,
because then you couldn't separate the properties for *that subvol*
from the ones for the whole FS (say, the default replication policy,
where you might want the top subvol to have different properties from
everything else).

Possibly do special names for the defaults and store them there? In general, I personally see little value in having some special 'default' properties however.

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), or from the next higher subvolume it's nested in. This would obviate the need for some special 'default' properties, and would be relatively intuitive behavior for a significant majority of people.

smime.p7s
Description: S/MIME Cryptographic Signature