On 12/11/19 9:01 AM, Qu Wenruo wrote:
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.
To keep the ball rolling I can run stress tests part here,
yep need extra suggestions on the stress test tools.
Thanks, Anand
- 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.
