public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: miklos@szeredi.hu, aia21@cam.ac.uk, arjan@infradead.org,
	linux-kernel@vger.kernel.org, frankvm@frankvm.com
Subject: Re: FUSE merging?
Date: Fri, 1 Jul 2005 04:29:55 -0700	[thread overview]
Message-ID: <20050701042955.39bf46ef.akpm@osdl.org> (raw)
In-Reply-To: <E1DoIUz-0002a5-00@dorka.pomaz.szeredi.hu>

Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> > > Well, there's the "unsolvable" writeback deadlock problem, that FUSE
> > > works around by not buffering dirty pages (and not allowing writable
> > > mmap).  Does NFS solve that?  I'm interested :)
> > 
> > I don't know - first you'd have to describe it.
> 
> A dirty page is being written back, but the userspace server needs to
> allocate memory to complete the request.  But the allocation will
> block, since there's no more free memory.  

That shouldn't happen with write() traffic due to the dirty memory
balancing logic.

It'll happen with MAP_SHARED.  Totally disallowing MAP_SHARED sounds a bit
drastic, but of course nfs/v9fs could be taught to do that.

> > > Then there's the usual "filesystem recursing into itself" deadlock.
> > 
> > Describe this completely as well, please.
> 
> User does unlink("/mnt/userfs/file").  Userspace server receives
> request to unlink "/file".  Then the daemon does
> unlink("/mnt/userfs/file").  This will deadlock on i_sem.

eh?  How can the fuse client and the fuse server both get access to the
same file in this manner?  I don't see how you could set that up with NFS,
for example.

> > > Userspace can tell the kernel, how long a dentry should be valid.  I
> > > don't think the NFS protocol provides this. Same holds for the inode
> > > attributes.
> > 
> > Why is that needed?
> 
> Because, I can well imagine a synthetic filesystem, where file
> data/metadata change aribitrarily.  In this case the timeout heuristic
> in NFS is not useful.
> 
> In fact with NFS it's often a PITA, that it doesn't want to refresh a
> file's data/metatata, which I _know_ has changed on the server.

I think nfs can do this, as long as the modification was done through the
server.  I'd expect v9fs would be the same.

> > Plus NFS and v9fs work across the network...
> 
> Yes.  I consider that a drawback.

Others (many) would disagree.


Sorry, but I'm not buying it.  I still don't see a solid reason why all
this could not be done with nfs/v9fs, some kernel tweaks and the rest in
userspace.  It would take some effort, but that effort would end up
strengthening existing kernel capabilities rather than adding brand new
things, which is good.

  reply	other threads:[~2005-07-01 11:31 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-30  9:19 FUSE merging? Miklos Szeredi
2005-06-30  9:27 ` Andrew Morton
2005-06-30  9:51   ` Miklos Szeredi
2005-06-30 10:00     ` Arjan van de Ven
2005-06-30 10:12       ` Miklos Szeredi
2005-06-30 10:20         ` Arjan van de Ven
2005-06-30 10:24           ` Miklos Szeredi
2005-06-30 19:39             ` Avuton Olrich
2005-07-01  6:23               ` Miklos Szeredi
2005-06-30 11:13           ` Anton Altaparmakov
2005-06-30 19:46             ` Andrew Morton
2005-06-30 20:00               ` Andrew Morton
2005-07-01  6:40                 ` Miklos Szeredi
2005-06-30 22:28               ` Frank van Maarseveen
2005-07-01  6:58                 ` Miklos Szeredi
2005-07-01  9:24                   ` Frank van Maarseveen
2005-07-01 10:27                     ` Miklos Szeredi
2005-07-01 12:00                       ` Frank van Maarseveen
2005-07-01 12:36                         ` Miklos Szeredi
2005-07-01 13:05                           ` Frank van Maarseveen
2005-07-01 13:21                             ` Miklos Szeredi
2005-07-01 15:20                               ` Frank van Maarseveen
2005-07-01 17:04                                 ` Miklos Szeredi
2005-07-01 18:04                                   ` Frank van Maarseveen
2005-07-01 19:35                                     ` Jeremy Maitin-Shepard
2005-07-02 14:49                                     ` Miklos Szeredi
2005-07-02 16:00                                       ` Frank van Maarseveen
2005-07-03  6:16                                         ` Miklos Szeredi
2005-07-03 11:25                                           ` Frank van Maarseveen
2005-07-03 13:24                                             ` Miklos Szeredi
2005-07-03 13:50                                               ` Frank van Maarseveen
2005-07-03 14:03                                                 ` Miklos Szeredi
2005-07-03 14:10                                               ` FUSE merging? (2) Frank van Maarseveen
2005-07-03 15:47                                                 ` Miklos Szeredi
2005-07-03 19:36                                                   ` Frank van Maarseveen
2005-07-04  8:56                                                     ` Miklos Szeredi
2005-07-04  9:59                                                       ` Frank van Maarseveen
2005-07-04 10:27                                                         ` Miklos Szeredi
2005-07-04 11:26                                                           ` Frank van Maarseveen
2005-07-01  6:36               ` FUSE merging? Miklos Szeredi
2005-07-01  6:50                 ` Andrew Morton
2005-07-01  7:07                   ` Miklos Szeredi
2005-07-01  7:14                     ` Andrew Morton
2005-07-01  7:27                       ` Miles Bader
2005-07-01  7:38                       ` Miklos Szeredi
2005-07-01  8:02                         ` Andrew Morton
2005-07-01 10:11                           ` Miklos Szeredi
2005-07-01 11:29                             ` Andrew Morton [this message]
2005-07-01 12:00                               ` Miklos Szeredi
2005-07-01 12:53                               ` Anton Altaparmakov
2005-07-01 13:07                                 ` Anton Altaparmakov
2005-07-01 13:51                                 ` Frank van Maarseveen
2005-07-01 13:29                               ` Eric Van Hensbergen
2005-07-01 16:45                               ` Matthias Urlichs
2005-07-01 12:08                             ` Frank van Maarseveen
2005-07-01 13:21                             ` Eric Van Hensbergen
2005-07-01 13:53                               ` Miklos Szeredi
2005-07-01 14:18                                 ` Eric Van Hensbergen
2005-07-01 14:31                                   ` Miklos Szeredi
2005-07-02 10:01                                     ` Eric W. Biederman
2005-07-02 14:58                                       ` Miklos Szeredi
2005-07-02 16:43                                       ` Eric Van Hensbergen
2005-07-02 17:33                                         ` Eric W. Biederman
2005-07-03 19:39                           ` Pavel Machek
2005-07-04  8:38                             ` Miklos Szeredi
     [not found]                               ` <20050704084900.GG15370@elf.ucw.cz>
2005-07-04  9:02                                 ` Miklos Szeredi
2005-07-04 10:46                                   ` Pekka Enberg
2005-07-01 12:37                   ` bert hubert
2005-07-01  7:46                 ` Frederik Deweerdt
2005-07-01  9:47                   ` Miklos Szeredi
2005-07-01  9:36                 ` Frank van Maarseveen
2005-07-01 10:45                   ` Miklos Szeredi
2005-07-01 11:34                     ` Frank van Maarseveen
2005-06-30 10:16       ` Miklos Szeredi
2005-06-30 16:30         ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2005-09-02 22:02 Miklos Szeredi
2005-09-02 22:34 ` Andrew Morton
2005-09-03  0:34   ` Kasper Sandberg
2005-09-03  5:31   ` Miklos Szeredi
2005-09-03  6:40     ` Andrew Morton
2005-09-03  7:23       ` Miklos Szeredi
2005-09-03 13:29     ` Eric Van Hensbergen
2005-09-03 14:20       ` Miklos Szeredi
2005-09-03 15:01         ` Eric Van Hensbergen
2005-09-03 15:38           ` Miklos Szeredi

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=20050701042955.39bf46ef.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=aia21@cam.ac.uk \
    --cc=arjan@infradead.org \
    --cc=frankvm@frankvm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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