On Mon, 16 Jul 2001 13:00, Nikita Danilov 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...
>
> If you have 10000 clients each opening 100 files you got 1e6 opened
> files on the server---it wouldn't work. NFS was designed to be stateless
> to be scalable.
If you want performance from a file server that is almost bearable then you
must have enough cache to handle all the open files.
10^6 files will not be workable anyway. If each file is accessed once per
hour then the load might almost be bearable by high-end hardware.
Memory is getting cheaper all the time. I've worked with many server
machines that have 2G or more of RAM. Having enough kernel memory for 1M
open files should be easy enough to manage (I could probably manage it on my
laptop if I upgraded it).
Being able to actually do anything with 1M processes accessing files at the
same time is another issue.
I am surprised to hear about NFS being stateless for large performance. I
always thought that it was stateless because it pre-dates the common
availability of UPSs and hardware RAID (or any RAID really). Also NFS
pre-dates the availability of HACMP, E10K, and other systems to bring
mainframe features of hot-swap hardware and high reliability to Unix systems.
--
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
|