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:
signature.asc
Description: OpenPGP digital signature
