Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754640Ab0BJKCi (ORCPT ); Wed, 10 Feb 2010 05:02:38 -0500 Received: from mail.up.ac.za ([137.215.6.44]:35447 "EHLO mail.up.ac.za" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752878Ab0BJKCh (ORCPT ); Wed, 10 Feb 2010 05:02:37 -0500 Message-ID: <4B728418.4050807@up.ac.za> Date: Wed, 10 Feb 2010 12:02:00 +0200 From: Paul Schutte User-Agent: Icedove 1.5.0.14eol (X11/20090105) MIME-Version: 1.0 To: Paul Schutte CC: Goswin von Brederlow , Miklos Szeredi , fuse-devel@lists.sourceforge.net, lkml , Tejun Heo , Lars Wendler , Andrew Morton Subject: Re: [fuse-devel] [PATCH] FUSE/CUSE: implement direct mmap support References: <4B70FBE4.7050700@kernel.org> <87k4ulo5w2.fsf@frosties.localdomain> <4B727535.6060701@up.ac.za> In-Reply-To: <4B727535.6060701@up.ac.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3251 Lines: 82 Sorry wrong thread ! Paul Schutte wrote: > Hi. > > I am just sharing my thoughts on the matter. > > Maybe one can implement a separate "fuse sync" ioctl which can then be > called by a user space program say "fusersync" to sync all the fuse > filesystems you are allowed to. > > I implemented sync to my filesystem by means of an extended attribute. > I now do "setfattr -nsync /mountpoint" to get the syncing done. > > This has the drawback that you can not easily put it in a script because > you need to know the mount point. I know one can write smart scripts to > figure out the mountpoint, but it would be nice if you can just say > "fusersync" and all the fuse filesystems that you are allowed to will > just sync. > > One can then maybe rename the system wide sync to say "sync.system" and > put a script in it's place which calls "fusersync;sync.system" > > Hopefully this idea might be useful. > > Regards > Paul > > Goswin von Brederlow wrote: > >> Tejun Heo writes: >> >> >> >>> Implement FUSE direct mmap support. The server can redirect client >>> mmap requests to any SHMLBA aligned offset in the custom address space >>> attached to the fuse channel. The address space is managed by the >>> server using mmap/munmap(2). The SHMLBA alignment requirement is >>> necessary to avoid cache aliasing issues on archs with virtually >>> indexed caches as FUSE direct mmaps are basically shared memory >>> between clients and the server. >>> >>> The direct mmap address space is backed by pinned kernel pages which >>> are allocated on the first fault either from a client or the server. >>> If used carelessly, this can easily waste and drain memory. >>> Currently, a server must have CAP_SYS_ADMIN to manage dmmap regions by >>> mmapping and munmapping the channel fd. >>> >>> >> Does that mean that for example in unionfs-fuse when a user wants to >> mmap a file I can just mmap the actual underlying file from the real >> filesystem and any read/write access would then shortcut fuse and go >> directly to the real file? >> >> MfG >> Goswin >> >> ------------------------------------------------------------------------------ >> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, >> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW >> http://p.sf.net/sfu/solaris-dev2dev >> _______________________________________________ >> fuse-devel mailing list >> fuse-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/fuse-devel >> >> > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > fuse-devel mailing list > fuse-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fuse-devel > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/