Hi Sam,
I wanted to clarify ObjectStore::fiemap API and sparse-read OSD op
guarantees as this came up in Jeff's fscrypt work and just recently in
RBD as well.
In fscrypt for kcephfs, Jeff has opted to use sparse-read to ensure
that file holes (which must contain all zeroes logically) don't get
"decrypted" into seemingly random junk. (Unlike ecryptfs, fscrypt
framework doesn't attempt to protect the information about existence
and location of holes in files, so logical holes generally correspond
to physical holes.)
This seems to be working with Bluestore on replicated pools because it
tracks the allocated extents at byte level, irrespective of the actual
data block size (bluestore_min_alloc_size, etc). However sparse-read
is built on ObjectStore::fiemap and there is the following comment in
src/os/ObjectStore.h on fiemap:
* A non-enlightened implementation is free to return the extent
* (offset, len) as the sole extent.
Is that true? If not, is the implementation required to track
everything at byte level or is it allowed to pick a granularity?
What is SeaStore going to do here?
Going further, on EC pools, sparse-read is currently converted into
a regular (async) read right away which is the same as fiemap returning
a sole extent as far as the client is concerned. Can EC pool support
be expected in the future?
The reason I'm asking is that I have always considered sparse-read to
be a "read with a hint" operation, where the hint to skip unallocated
extents can be ignored by the OSD. The above use case goes against
that as it requires precise sub-object extent mappings. Putting EC
pools aside for the moment, is sparse-read safe to use for this
purpose?
Thanks,
Ilya
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
