Re: [btrfs-progs] Bug in mkfs.btrfs -r

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2017年09月01日 19:28, Austin S. Hemmelgarn wrote:
> On 2017-08-31 20:13, Qu Wenruo wrote:
>>
>>
>> On 2017年09月01日 01:27, Goffredo Baroncelli wrote:
>>> Hi All,
>>>
>>>
>>> I found a bug in mkfs.btrfs, when it is used the option '-r'. It 
>>> seems that it is not visible the full disk.
>>
>> Despite the new bug you found, -r has several existing bugs.
> Is this actually a bug though?  Every other filesystem creation  tool 
> that I know of that offers functionality like this generates the 
> filesystem just large enough to contain the data you want in it,

At least I tried mkfs.ext4 with an almost empty directory (only one 512K 
file),
After mount the fs, there is still over 900M available space.

Even mkfs.ext4 doesn't explain much about its -d option, I think it's 
not the case, at least for -d option alone.

Thanks,
Qu

> so I 
> would argue that making this use the whole device is actually breaking 
> consistency with other tools, not to mention removing functionality that 
> is useful (even aside from the system image generation use case I 
> mentioned, there are other practical applications (seed 'device' 
> generation comes to mind).
>>
>> For example it will create dev extent starting from physical offset 0, 
>> while kernel and mkfs will avoid that range, as 0~1M on each device is 
>> reserved.
>>
>> According to the code, -r will modify chunk layout by itself, not the 
>> traditional way kernel is doing.
>>
>> I'll fix them (if I'm not a lazybone), before that fix, please don't 
>> use -r option as it's not well maintained or fully tested.
> FWIW, based on my own testing, filesystems generated with '-r' work just 
> fine as long as you don't try to embed boot code in the FS itself.
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html