mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: pavel@suse.cz, Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Alexander Viro <viro@math.psu.edu>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Simon Richter <Simon.Richter@phobos.fachschaften.tu-muenchen.de>,
	Jonathan Barker <jbarker@ebi.ac.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: VFS mediator?
Date: Tue, 19 Mar 2002 07:45:15 -0600 (CST)	[thread overview]
Message-ID: <200203191345.HAA74864@tomcat.admin.navo.hpc.mil> (raw)

Pavel Machek <pavel@suse.cz>:
> Hi!
> 
> >      > Okay, take userland nfs-server. (This thread was about userland
> >      > filesystems).
> > 
> > Yech... Nobody should be seriously considering using unfsd: it does
> > not even manage to follow the NFS protocol. That inability was one of
> > the many reasons why Olaf Kirch abandoned further develpement of unfsd
> > and started work on knfsd.
> > 
> >      > Then, make memory full of dirty pages. Imagine that nfs-server
> >      > is swapped-out by some bad luck. What you have is extremely
> >      > nasty deadlock, AFAICS. [To free memory you have to write out
> >      > dirty data, but you can't do that because you don't have enough
> >      > memory for nfs-server].
> > 
> > So that is another argument for using knfsd rather than unfsd. I will
> > agree with you that NFS is not perfect, but please judge it on its
> > actual merits and not on some trumped up charge...
> 
> Sorry, this thread was about userland filesystems, and NFS is just not
> usefull there (for read/write case).

Assuming, of course, that the daemon doesn't mprotect itself...

A user mode file system is really only good at debugging a design.

All file migration style filesystems, and user mode filesystems, have this
same problem on paging based systems:

Can't write buffer until file is migrated (file system full),
Can't migrate file until buffer memory is freed....
system hung...

Although it is usually possible to detect this deadlock and abort some
process, freeing memory (and sometimes disk space at the same time).

Swapping systems can have the equivalent problem if swap space is
oversubscribed.

The problem boils down to the same solution - don't oversubscribe memory...

I know this is a bit of a troll, but memory controls are necessary to
detect, avoid, or repair the situation.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

             reply	other threads:[~2002-03-19 13:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-19 13:45 Jesse Pollard [this message]
2002-03-19 21:24 ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2002-03-14 14:52 Jonathan Barker
2002-03-14 23:09 ` Simon Richter
2002-03-14 23:33   ` Alan Cox
2002-03-15  0:00     ` Alexander Viro
2002-03-15 11:50       ` Simon Richter
2002-03-18 19:25       ` Pavel Machek
2002-03-18 22:18         ` Trond Myklebust
2002-03-18 22:38           ` Pavel Machek
2002-03-18 22:48             ` Trond Myklebust
2002-03-18 22:54               ` Pavel Machek
2002-03-18 23:05                 ` Trond Myklebust
2002-03-19  0:15           ` Alan Cox
2002-03-18 22:29         ` Alexander Viro
2002-03-18 22:36           ` Pavel Machek
2002-03-15 14:28 ` Jonathan Barker

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=200203191345.HAA74864@tomcat.admin.navo.hpc.mil \
    --to=pollard@tomcat.admin.navo.hpc.mil \
    --cc=Simon.Richter@phobos.fachschaften.tu-muenchen.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jbarker@ebi.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=trond.myklebust@fys.uio.no \
    --cc=viro@math.psu.edu \
    /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

all inboxes | Powered by JetHome®