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

From: Hugo Mills <hugo@carfax.org.uk>
To: "Holger Hoffstätte" <holger.hoffstaette@googlemail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: Fix no space bug caused by removing bg
Date: Tue, 22 Sep 2015 13:41:31 +0000	[thread overview]
Message-ID: <20150922134131.GH5918@carfax.org.uk> (raw)
In-Reply-To: <5601596B.1020607@googlemail.com>

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

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.

> > allocated as a placeholder is a bit much.  Beyond that, I've been
> 
> Can you explain why keeping at least one data chunk (or the appropriate
> number across devices, depending on RAID level..) is "a bit much"?
> IMHO this would have no real negative impact on end users (who think
> in terms of overall filesystem space, not how much of that has been
> lazily touched), nor for more obscure use cases like sparse images -
> which would still be sparsely reserved. So there would not be any
> actual downside that I can see. From a fs consistency point of view
> it sounds much more sane to assume that at least a basic set of data
> chunks always need to exist. I know I was very surprised recently to
> see all my data chunks cleaned up on an otherwise empty fs.
> I mean..it's good to see that the house cleaning works, but you also
> gotta know when to stop!
> 
> > thinking casually about ways to direct the allocator to use certain
> > devices for certain things (e.g. in a hybrid system with SSDs and
> > HDDs, always allocate metadata on the SSD) and there's some overlap
> > there.  As it stands, we can fake that in mkfs but it'll get stomped
> > by balance nearly immediately.
> 
> Please share those casual thoughts with the group. :)

   I had some as well last year (see my other mail). I hope they line
up with Jeff's. :)

   Hugo.

-- 
Hugo Mills             | "Big data" doesn't just mean increasing the font
hugo@... carfax.org.uk | size.
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]