[Top] [All Lists]

Re: [reiserfs-list] Re: benchmarks

To: Russell Coker <russell@xxxxxxxxxxxx>
Subject: Re: [reiserfs-list] Re: benchmarks
From: Hans Reiser <reiser@xxxxxxxxxxx>
Date: Mon, 16 Jul 2001 14:40:31 +0400
Cc: Chris Wedgwood <cw@xxxxxxxx>, rsharpe@xxxxxxxxxx, Xuan Baldauf <xuan--reiserfs@xxxxxxxxxxx>, Seth Mos <knuffie@xxxxxxxxx>, Federico Sevilla III <jijo@xxxxxxxxxxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx, reiserfs-list@xxxxxxxxxxx
Organization: Namesys
References: <Pine.BSI.4.10.10107141752080.18419-100000@xs3.xs4all.nl> <3B5169E5.827BFED@namesys.com> <20010716210029.I11938@weta.f00f.org> <20010716101313.2DC3E965@lyta.coker.com.au>
Sender: owner-linux-xfs@xxxxxxxxxxx
Russell Coker wrote:
> On Mon, 16 Jul 2001 11:00, Chris Wedgwood wrote:
> > On Sun, Jul 15, 2001 at 02:01:09PM +0400, Hans Reiser wrote:
> >
> >     Making the server stateless is wrong
> >
> > why?
> Because it leads to all the problems we have seen!  Why not have the client
> have an open file handle (the way Samba works and the way the Unix file
> system API works)?  Then when the server goes down the client sends a request
> to open the file again...
> >     making the readdir a multioperation act is wrong
> >
> > why? i have 3M directories... ar you saying clients should read the
> > whole things at once?
> No.  findfirst()/findnext() is the correct way of doing this.  Forcing the
> client to read through 3M directory entries to see if "foo.*" matches
> anything is just wrong.  The client should be able to ask for a list of file
> names matching certain criteria (time stamp, name, ownership, etc).  The
> findfirst() and findnext() APIs on DOS, OS/2, and Windows do this quite well.

there is a fundamental conflict between having cookies, shrinkable directories, 
and the ability to
find foo.* without reading the whole directory, all at the same time.  

NFS V4 is designed by braindead twerps incapable of layering software when 
designing it.

> If you have 3M directory entries then SMB should kick butt over NFS.
> Also while we're at it, one of the worst things about NFS is the issue of
> delete.  Because it's stateless NFS servers implement unlink as "mv" and
> things get nasty from there...
> --
> http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
> http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
> http://www.coker.com.au/projects.html Projects I am working on
> http://www.coker.com.au/~russell/     My home page

<Prev in Thread] Current Thread [Next in Thread>