Russell Coker wrote: > > On Thu, 27 Jul 2000, Catalin Ciocoiu wrote: > >In a slashdot articol somebody lace a interesing question.... > >What is the best solution for a network width 2500 Linux WorkStation ? > >I proposed a diskless workstation sollution becose is very robust > >sollution. > >Is it a good sollution ???? > >What filesystem can be used for file sharing ?? Is NFS ok ??? > >What kind of authentification can be used in this network ? > > > >I waiting your answares !! > > One problem with diskless workstations is the issue of what happend when they > all reboot simultaneously (EG power failure). I suggest that you setup a > diskless workstation that is fully configured (X, xdm, etc), reboot it and > track the amount of data transfer that is required. I guess that it might be > about 30M of data access on disk. Multiply that by 2500 and that's 75G of > data transfer, it would be 2 hours of network transfer on 100baseT if you > didn't have timeouts and retransmits. Of course with that load you would > have heaps of timeouts and it would take much longer...
Whell .... On this network can be more than 1 fileserver and the traffic can be splited on more network segment. One file server for 50-100 station can be ok ! The file server for 100 station is on the same net segment width the station. This can reduce subtantial net traffic over segments. The /usr dir can be the same. And most files on the slash can be hard link for the same inod( eg: /bin/ls ). > > The good thing about diskless booting is that all machines will access mostly > the same files if you have it configured correctly. The boot space of a > diskless machine should fit into cache on the server (so disk bandwidth > shouldn't be an issue). If you have a server with 10 * 100baseT network > interfaces or 1 * 1G interface (the most that the bus bandwidth of typical PC > servers can handle) then it could possibly handle 800 PCs for booting in a > reasonable amount of time (5-10 minutes). So if you had 4 such machines for > running the boot process (IE the root file system) and another set of > machines for /home (which is much harder because the data is more important) > then it could be workable. > > One thing I have been thinking of doing (an item on my almost infinitely long > todo list) is to hack a kernel to log the details of file access (file name > and the operation (read/write/etc) and the amount of data to klog and then > have a modified klogd write this data to a file which is outside this logging > (can't have it logging it's own accesses ;). Then I could boot the machine > (NB would need a extra-large klogd buffer to capture file access before klogd > had been loaded) and find out how much disk access really happens at boot. > > -- > My current location - X marks the spot. > X > X > X > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]