From: Paul Schutte <paul@up.ac.za>
To: Paul Schutte <paul@up.ac.za>
Cc: Goswin von Brederlow <goswin-v-b@web.de>,
Miklos Szeredi <mszeredi@suse.cz>,
fuse-devel@lists.sourceforge.net,
lkml <linux-kernel@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
Lars Wendler <polynomial-c@gentoo.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [fuse-devel] [PATCH] FUSE/CUSE: implement direct mmap support
Date: Wed, 10 Feb 2010 12:02:00 +0200 [thread overview]
Message-ID: <4B728418.4050807@up.ac.za> (raw)
In-Reply-To: <4B727535.6060701@up.ac.za>
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 <tj@kernel.org> 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
>
prev parent reply other threads:[~2010-02-10 10:02 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-09 6:08 [PATCH] FUSE/CUSE: implement direct mmap support Tejun Heo
2010-02-09 14:59 ` [fuse-devel] " Miklos Szeredi
2010-02-10 11:22 ` Tejun Heo
2010-02-10 11:29 ` Miklos Szeredi
2010-02-10 11:56 ` Tejun Heo
2010-02-10 12:15 ` Miklos Szeredi
2010-02-10 12:35 ` Tejun Heo
2010-02-10 15:02 ` Miklos Szeredi
2010-02-10 23:43 ` Tejun Heo
2010-02-11 9:31 ` Miklos Szeredi
2010-02-11 9:51 ` Miklos Szeredi
2010-02-11 11:54 ` Tejun Heo
2010-02-11 12:25 ` Miklos Szeredi
2010-02-11 12:49 ` Tejun Heo
2010-02-11 12:46 ` Miklos Szeredi
2010-02-11 13:05 ` Tejun Heo
2010-02-11 13:08 ` Miklos Szeredi
2010-02-11 13:40 ` Tejun Heo
2010-02-11 11:47 ` Tejun Heo
2010-02-11 12:34 ` Miklos Szeredi
2010-02-11 12:56 ` Tejun Heo
2010-02-11 13:01 ` Miklos Szeredi
2010-02-11 13:30 ` Tejun Heo
2010-02-11 13:40 ` Miklos Szeredi
2010-02-11 13:58 ` Tejun Heo
2010-02-11 14:40 ` Miklos Szeredi
2010-02-12 0:07 ` Tejun Heo
2010-02-12 0:25 ` Tejun Heo
2010-02-12 9:55 ` Miklos Szeredi
2010-02-12 13:33 ` Tejun Heo
2010-02-12 13:53 ` Miklos Szeredi
2010-02-12 17:56 ` Tejun Heo
2010-02-10 11:36 ` Tejun Heo
2010-02-10 8:24 ` Goswin von Brederlow
2010-02-10 8:40 ` Miklos Szeredi
2010-02-10 8:58 ` Paul Schutte
2010-02-10 10:02 ` Paul Schutte [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B728418.4050807@up.ac.za \
--to=paul@up.ac.za \
--cc=akpm@linux-foundation.org \
--cc=fuse-devel@lists.sourceforge.net \
--cc=goswin-v-b@web.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mszeredi@suse.cz \
--cc=polynomial-c@gentoo.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox