public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
>   

      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