Automatic balance after mkfs?

Automatic balance after mkfs?

[Holger Hoffstätte]

Forking from the other thread..

On Tue, 16 Jun 2015 12:25:45 +0000, Hugo Mills wrote:

>    Yes. It's an artefact of the way that mkfs works. If you run a
> balance on those chunks, they'll go away. (btrfs balance start
> -dusage=0 -musage=0 /mountpoint)

Since I had to explain this very same thing to a new btrfs-using friend
just yesterday I wondered if it might not make sense for mkfs to issue
a general balance after creating the fs? It should be simple enough
(just issue the balance ioctl?) and not have any negative side effects.

Just doing such a post-mkfs cleanup automatically would certainly
reduce the number of times we have to explain the this. :)

Any reasons why we couldn't/shouldn't do this?

-h

Re: Automatic balance after mkfs?

[Austin S Hemmelgarn]

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

On 2015-06-16 09:13, Holger Hoffstätte wrote:
>
> Forking from the other thread..
>
> On Tue, 16 Jun 2015 12:25:45 +0000, Hugo Mills wrote:
>
>>     Yes. It's an artefact of the way that mkfs works. If you run a
>> balance on those chunks, they'll go away. (btrfs balance start
>> -dusage=0 -musage=0 /mountpoint)
>
> Since I had to explain this very same thing to a new btrfs-using friend
> just yesterday I wondered if it might not make sense for mkfs to issue
> a general balance after creating the fs? It should be simple enough
> (just issue the balance ioctl?) and not have any negative side effects.
>
> Just doing such a post-mkfs cleanup automatically would certainly
> reduce the number of times we have to explain the this. :)
>
> Any reasons why we couldn't/shouldn't do this?
>
Following the same line of thinking, is there any reason we couldn't 
just rewrite mkfs to get rid of this legacy behavior?



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

Re: Automatic balance after mkfs?

[Qu Wenruo]

Austin S Hemmelgarn wrote on 2015/06/16 09:21 -0400:
> On 2015-06-16 09:13, Holger Hoffstätte wrote:
>>
>> Forking from the other thread..
>>
>> On Tue, 16 Jun 2015 12:25:45 +0000, Hugo Mills wrote:
>>
>>>     Yes. It's an artefact of the way that mkfs works. If you run a
>>> balance on those chunks, they'll go away. (btrfs balance start
>>> -dusage=0 -musage=0 /mountpoint)
>>
>> Since I had to explain this very same thing to a new btrfs-using friend
>> just yesterday I wondered if it might not make sense for mkfs to issue
>> a general balance after creating the fs? It should be simple enough
>> (just issue the balance ioctl?) and not have any negative side effects.
>>
>> Just doing such a post-mkfs cleanup automatically would certainly
>> reduce the number of times we have to explain the this. :)
>>
>> Any reasons why we couldn't/shouldn't do this?
>>
> Following the same line of thinking, is there any reason we couldn't
> just rewrite mkfs to get rid of this legacy behavior?
>
>
Compared to the more complex auto balance, rewrite mkfs is a much better 
idea.

The original mkfs seems easy for developers, but bad for users.

I like the idea and I'll try to implment it if I have spare time.

Thanks.
Qu

Re: Automatic balance after mkfs?

[David Sterba]

On Thu, Jun 18, 2015 at 01:41:07PM +0800, Qu Wenruo wrote:
> >>>     Yes. It's an artefact of the way that mkfs works. If you run a
> >>> balance on those chunks, they'll go away. (btrfs balance start
> >>> -dusage=0 -musage=0 /mountpoint)
> >>
> >> Since I had to explain this very same thing to a new btrfs-using friend
> >> just yesterday I wondered if it might not make sense for mkfs to issue
> >> a general balance after creating the fs? It should be simple enough
> >> (just issue the balance ioctl?) and not have any negative side effects.
> >>
> >> Just doing such a post-mkfs cleanup automatically would certainly
> >> reduce the number of times we have to explain the this. :)
> >>
> >> Any reasons why we couldn't/shouldn't do this?
> >>
> > Following the same line of thinking, is there any reason we couldn't
> > just rewrite mkfs to get rid of this legacy behavior?

The 'single' blockgroups on multidevice filesystem are considered a bug
in mkfs, an annoying and long running one.

> Compared to the more complex auto balance, rewrite mkfs is a much better 
> idea.

Balance is a workaround besides that it requires mouting.

> The original mkfs seems easy for developers, but bad for users.

I'd argue that mkfs is primarily for users.

Re: Automatic balance after mkfs?

[Hugo Mills]

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

On Tue, Jun 16, 2015 at 01:13:40PM +0000, Holger Hoffstätte wrote:
> 
> Forking from the other thread..
> 
> On Tue, 16 Jun 2015 12:25:45 +0000, Hugo Mills wrote:
> 
> >    Yes. It's an artefact of the way that mkfs works. If you run a
> > balance on those chunks, they'll go away. (btrfs balance start
> > -dusage=0 -musage=0 /mountpoint)
> 
> Since I had to explain this very same thing to a new btrfs-using friend
> just yesterday I wondered if it might not make sense for mkfs to issue
> a general balance after creating the fs? It should be simple enough
> (just issue the balance ioctl?) and not have any negative side effects.

   Mount, balance, unmount... You can't balance on an unmounted FS.
You'd also have to write something to the FS (see below).

> Just doing such a post-mkfs cleanup automatically would certainly
> reduce the number of times we have to explain the this. :)
> 
> Any reasons why we couldn't/shouldn't do this?

   On an empty filesystem, it used to throw away the RAID
configuration, which was identified from the existing chunks on the
FS. With no chunks remaining, the RAID configuration reverted to
single all round (IIRC). I don't know if that's been fixed since those
days, but it's something to be wary of, at the very least.

   I've added the question as an entry to the FAQ, anyway.

   Hugo.

-- 
Hugo Mills             | vi vi vi: the Editor of the Beast.
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

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