Whamcloud - gitweb
EX-7601 ofd: series description and reorder declarations
Reorder declarations in tgt_brw_read prior to adding things.
This trivial patch is a good place to put the description
of this series, which handles unaligned reads to compressed
files.
-----------------------
These patches handle compression chunk unaligned reads on
the server.
When using compression, the client attempts to send chunk
aligned reads, but sometimes it can't, and the client will
send a read to the server which is not chunk aligned.
In this case, the server must read the full chunk,
decompress it, and provide the requested data to the client.
Here's how we do this.
The server receives a set of remote niobufs describing IO
from the client. Each remote niobuf (rnb) describes a range
of data the client wants to do IO to.
These are translated to a set of local niobufs on the
server, which we then use to do the read. For compression,
the server has to read complete chunks on unalinged reads.
So we walk these remote niobufs and identify unaligned read
requests (in ofd_preprw_read), then round them to chunk
size. The server then reads the chunk rounded read request
from storage.
The local niobufs now contain a set of complete compressed
chunks, ie, the raw data from disk. We need to decompress
the chunks where the client is doing an unaligned read, but
leave the other chunks compressed (because the client will
uncompress them).
So, in obd_decompress_read, we use the remote niobuf to
identify unaligned reads from the client. We then walk the
local niobufs, identify the chunks which match the unaligned
reads from the client, and decompress them 'in place'.
The decompression uses temporary buffers, but the
decompressed data is placed back in the local niobuf.
(If the data is uncompressed on disk, we of course do not
decompress it. This happens for incompressible data.)
Now the local niobuf contains some raw chunks and some
chunks which have been decompressed. This is *more* data
than the client asked for. Normally, the server local
niobuf contains exactly what the client asked for, so the
server checksums and sends the entire local niobuf. But
because we read complete chunks, the local niobuf contains
more data than the client requested.
This means we need to identify the subset of the local
niobuf which the client actually wants to read and present
that to the client.
In order to do that, we walk the local niobuf and use the
remote niobufs (the description of the pages the client
needs) and create a special tx niobuf which points to only
the pages the client wants (io_lnb_to_tx_lnb). Then we use
this tx niobuf for checksum and transfer to the client.
Test-Parameters: trivial
Signed-off-by: Patrick Farrell <pfarrell@whamcloud.com>
Change-Id: Ic89dcef7e169879725caa6cdef4619b9a76b2b37
Reviewed-on: https://review.whamcloud.com/c/ex/lustre-release/+/52915
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: Artem Blagodarenko <ablagodarenko@ddn.com>