On 2021/7/27 23:33, Darrick J. Wong wrote:
On Tue, Jul 27, 2021 at 04:30:16PM +0800, Chao Yu wrote:
On 2021/7/27 15:38, Eric Biggers wrote:
That's somewhat helpful, but I've been doing some more investigation and now I'm
even more confused. How can f2fs support non-overwrite DIO writes at all
(meaning DIO writes in LFS mode as well as DIO writes to holes in non-LFS mode),
given that it has no support for unwritten extents? AFAICS, as-is users can
I'm trying to pick up DAX support patch created by Qiuyang from huawei, and it
looks it faces the same issue, so it tries to fix this by calling sb_issue_zeroout()
in f2fs_map_blocks() before it returns.
I really hope you don't, because zeroing the region before memcpy'ing it
is absurd. I don't know if f2fs can do that (xfs can't really) without
pinning resources during a potentially lengthy memcpy operation, but you
/could/ allocate the space in ->iomap_begin, attach some record of that
to iomap->private, and only commit the mapping update in ->iomap_end.
Thanks for the suggestion, let me check this a little bit later, since now I
just try to stabilize the codes...
Thanks,
--D
easily leak uninitialized disk contents on f2fs by issuing a DIO write that
won't complete fully (or might not complete fully), then reading back the blocks
that got allocated but not written to.
I think that f2fs will have to take the ext2 approach of not allowing
non-overwrite DIO writes at all...
Yes,
Another option is to enhance f2fs metadata's scalability which needs to update layout
of dnode block or SSA block, after that we can record the status of unwritten data block
there... it's a big change though...
Thanks,
- Eric
