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
- run stress tests + the new feature
- 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
- 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.
