On Tue, 6 Oct 2026 at 01:37, John Groves <[email protected]> wrote: > I see the kernel-side rejects these s/size/chunk_size/ strip extents if they > are not all the same size. Why not put the chunk size in the header and let > the extents honestly describe the offset and range that they cover? > The current design can't test for sufficient strip extent sizes, although > it replaces code that did verify this.
Not adding chunk size to the header is intentional to keep the API as simple as possible. > However, the smoke tests passing isn't fully legit, because the patch to the > famfs fuse server passes the entire strip size on CYCLIC mappings, meaning > it just produces a concatenation of ranges - which does not achieve the > interleaving goal at all. That case degenerates to simple extents. Are you talking about the case where there are multiple simple extents each with a different striped mapping? That case is supported by the API, but not the implementation (since there was not test case). If you do a test case, I'll add the implementation. > To be specific: each chase/dereference that results in an L3 cache miss adds > a stall of (1 * MEMORY_LATENCY) to the fault time. This is the good reason > why I didn't do any chasing in the fault path of the famfs code that you're > replacing. Please benchmark against the in-kernel implementation. If there's significant (meaning it may have a real effect on a real-life workload) performance hit from using the rb-tree, then we can add an optimization. I don't want to add complexity without actually being able to measure the gain. > OK, one more. You're using the rbtree for indexing by file offset, which is > a zero-based non-sparse range in this case. If this could not be avoided > (which I think it can) you should use an xarray or radix tree for that... > right? Unlike xarray, the rb_tree API is one I'm familiar with. But nothing prevents switching to xarray if that's a better choice. Thanks, Miklos > > > > > Thanks, > > Miklos > > > > --- > > Changes since v1: > > > > - moved 3 prep patches to fuse.git#for-next > > - introduce FUSE_PASSTHROUGH_V2 (Amir) > > - lots of small fixes and cleanups (Amir, Sashiko) > > > > --- > > John Groves (1): > > dax: replace exported dax_dev_get() with non-allocating dax_dev_find() > > Golly, it seems like there's more than 1 patch worth of content from me here, > but the chipper/shredder might meet the letter of copyright law in some > jurisdictions... > > > > > Miklos Szeredi (7): > > fuse: add helpers for EIO return value with kernel message > > fuse: support 64 bit, server allocated backing ID > > fuse: support opening 64 bit backing ID > > fuse: add support for opening dax device as backing > > fuse: add extent map data structure > > fuse: add extent map I/O support > > fuse: add support for striped backing > > > > drivers/dax/super.c | 38 ++++- > > fs/fuse/Makefile | 2 +- > > fs/fuse/backing.c | 292 ++++++++++++++++++++++++++++++------- > > fs/fuse/dev.c | 21 +++ > > fs/fuse/dev.h | 3 + > > fs/fuse/dir.c | 3 +- > > fs/fuse/ext_map.c | 299 ++++++++++++++++++++++++++++++++++++++ > > fs/fuse/file.c | 16 +- > > fs/fuse/fuse_i.h | 72 +++++++-- > > fs/fuse/inode.c | 17 ++- > > fs/fuse/iomode.c | 108 +++++++------- > > fs/fuse/notify.c | 75 ++++++++++ > > fs/fuse/passthrough.c | 63 ++++---- > > include/linux/dax.h | 6 +- > > include/uapi/linux/fuse.h | 53 ++++++- > > 15 files changed, 904 insertions(+), 164 deletions(-) > > create mode 100644 fs/fuse/ext_map.c > > > > -- > > 2.54.0 > > > > John > >
