Support for I/O to a bitbucket

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

 



One of the annoying things in the iomap code is how we handle
block-misaligned I/Os.  Consider a write to a file on a 4KiB block size
filesystem (on a 4KiB page size kernel) which starts at byte offset 5000
and is 4133 bytes long.

Today, we allocate page 1 and read bytes 4096-8191 of the file into
it, synchronously.  Then we allocate page 2 and read bytes 8192-12287
into it, again, synchronously.  Then we copy the user's data into the
pagecache and mark it dirty.  This is a fairly significant delay for
the user who normally sees the latency of a memcpy() now has to wait
for two non-overlapping reads to complete.

What I'd love to be able to do is allocate pages 1 & 2, copy the user
data into it and submit one read which targets:

0-903: page 1, offset 0, length 904
904-5036: bitbucket, length 4133
5037-8191: page 2, offset 942, length 3155

That way, we don't even need to wait for the read to complete.

I envisage block allocating a bitbucket page to support devices which
don't have native support for bitbucket descriptors.  We'd also need a
fallback path for devices which don't support whatever alignment the
I/O is happening at ... but the block layer already has support for
bounce-buffering, right?

Anyway, I don't have time to take on this work, but I thought I'd throw
it out in case anyone's looking for a project.  Or if it's a stupid idea,
someone can point out why.



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

  Powered by Linux