> > > > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/