Re: [PATCH] btrfs: mkfs: Make no-holes as default mkfs incompat features

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

[-- Attachment #1.1: Type: text/plain, Size: 2346 bytes --]



On 2019/11/12 上午2:02, David Sterba wrote:
> On Mon, Nov 11, 2019 at 02:50:04PM +0800, Qu Wenruo wrote:
>> No-holes feature could save 53 bytes for each hole we have, and it
>> provides a pretty good workaround to prevent btrfs check from reporting
>> non-contiguous file extent holes for mixed direct/buffered IO.
>>
>> The latter feature is more helpful for developers for handle log-writes
>> based test cases.
> 
> Thanks. The plan to make no-holes default has been there for some time
> already. What it needs is a full round of testing and validation before
> making it default. And as defaults change rarely, I'd like to add
> free-space-tree as mkfs default as well, there's enough demand for that
> and we want to start deprecating v1 in the future.
> 
> I have in my near-top todo list to do that, with the following
> checklist:
> 
> - run fstests with various features together + the new default
>   - release build
>   - debugging build with UBSAN, KASAN and additional useful debugging
>     tools
Already running with no_holes for several previous releases.

Not to mention new btrfs specific log-writes test cases are all already
using this feature  to avoid btrfs check failure.

So I think this part should be OK.

> - run stress tests + the new feature

Any extra suggestions for the stress test tool?

Despite that, extra 24x7 host may be needed for this test.

> - check that the documentation covers the change
>   - mkfs.btrfs help string
>   - manual page of mkfs.btrfs: benefits, pros/cons, conversion to/from
>     the feature (if applicable), with example commands (if applicable)
>   - wiki documentation update

Forgot this part.
I'll add this info in next update.

Thanks,
Qu
> - verify that all commonly used tools work with it (image, check, tune)
> 
> For free-space-tree specifically, there's
> https://github.com/kdave/drafts/blob/master/btrfs/progs-fst-default.txt
> 
> I don't have objections to the patch, that's the easy part. The above is
> non-coding work and is namely making sure that the usecase and usability
> is good, or with known documented quirks.
> 
> Making it default in progs release 5.4 is IMO doable, there are probably
> 2-3 weeks before the release, but this task needs one or more persons
> willing to do the above.
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]