From: Pavel Machek <pavel@suse.cz>
To: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
Cc: pavel@suse.cz, Trond Myklebust <trond.myklebust@fys.uio.no>,
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 22:24:25 +0100 [thread overview]
Message-ID: <20020319212425.GH12260@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <200203191345.HAA74864@tomcat.admin.navo.hpc.mil>
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...
Even if it did, I'm not sure it would be safe. write() may need some
memory, too.
> A user mode file system is really only good at debugging a design.
Not agreed. I would not want ftpfs in kernel, yet its happy in
userland.
> 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),
Well, filesystem full is nasty case. [I wonder how coda solves that?]
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
next prev parent reply other threads:[~2002-03-19 21:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-19 13:45 VFS mediator? Jesse Pollard
2002-03-19 21:24 ` Pavel Machek [this message]
-- 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=20020319212425.GH12260@atrey.karlin.mff.cuni.cz \
--to=pavel@suse.cz \
--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=pollard@tomcat.admin.navo.hpc.mil \
--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;
as well as URLs for NNTP newsgroup(s).