Re: [PATCH v3 14/21] iomap: Sub-extent zeroing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26/07/2024 18:13, Christoph Hellwig wrote:
On Fri, Jul 26, 2024 at 03:29:48PM +0100, John Garry wrote:
I have been considering another approach to solve this problem.

In this patch - as you know - we zero unwritten parts of a newly allocated
extent. This is so that when we later issue an atomic write, we would not
have the problem of unwritten extents and how the iomap iterator will
create multiple BIOs (which is not permitted).

How about an alternate approach like this:
- no sub-extent zeroing
- iomap iter is changed to allocate a single BIO for an atomic write in
first iteration
- each iomap extent iteration appends data to that same BIO
- when finished iterating, we submit the BIO

Obviously that will mean many changes to the iomap bio iterator, but is
quite self-contained.

Yes, I also suggested that during the zeroing fix discussion.

Maybe missed that. I did notice https://lore.kernel.org/linux-xfs/ZmwJuiMHQ8qgkJDS@xxxxxxxxxxxxx, but got a different impression of your idea there (to this one).

There
is generally no good reason to start a new direct I/O bio if the
write is contiguous on disk and only the state of the srcmap is different.

Sure, so we don't need to worry about partially-completed writes, if that was a concern; and it would also mean dropping that unpleasant code change in xfs_iomap_write_unwritten() where the start/count fsb were being rounded out to the extent granule boundary.

This will also be a big win for COW / out of place overwrites.






[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux