Re: [RFC V2 12/18] famfs_fuse: Plumb the GET_FMAP message/response

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

 



On Sat, Aug 16, 2025 at 10:00:23AM -0500, John Groves wrote:
> On 25/08/14 11:05AM, Darrick J. Wong wrote:
> <snip>
> > It's possible that famfs could use the mapping upsertion notification to
> > upload mappings into the kernel.  As far as I can tell, fuse servers can
> > send notifications even when they're in the middle of handling a fuse
> > request, so the famfs daemon's ->open function could upload mappings
> > before completing the open operation.
> > 
> 
> Famfs dax mappings don't change (and might or might not ever change).
> Plus, famfs is exposing memory, so it must run at memory speed - which
> is why it needs to cache the entire fmap for any active file. That way
> mapping faults happen at lookup-in-fmap speed (which is order 1 for
> interleaved fmaps, and order-small-n for non-interleaved.
> 
> I wouldn't rule out ever using upsert, but probably not before we
> integrate famfs with PNFS, or some other major generalizing event.

Hrm?  No, you'd just make the famfs ->open function upsert all the
relevant mappings.  Since the mappings are all fully written and
(presumably) within EOF, they'll stay in the cache forever and you never
have to upload them ever again.

Though it's probably smarter to wait for the first ->iomap_begin to do
the upserting because you wouldn't want waste kernel memory until
something actually wants to do IO to the file.

--D

> Thanks,
> John
> 
> <snip>
> 
> 




[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