Diskless Workstations
Mike Smith
> armed with just enough info to be dangerous.
Flee!
> Would you recommend using diskless workstations? Would you rather be shot?
> I have read what the vendor's have to say but I would like to hear your
> advice.
Yes and no. There are pros and cons to both arrangements; the basic
tradeoff is centralisation vs. performance.
> It seems that running diskless has a serious advantage of using the same
> disk space for all of the programs that all the users need. 100baseT can
> compete with UW-SCSI bit for bit on bandwidth.
No it can't. And NFS doesn't compete for latency. But many users
don't need that sort of filesystem throughput.
> The only disadvantage that I can see is that the organization depends
> utterly on the network and the fileserver. I think that any organization
> that depends heavily on networking is stuck with this anyway.
Indeed. You can address some of the performance issues with dataless,
rather than diskless, workstations (local OS copy, local config
replicated on a regular basis from a master server, apps and user data
mounted via NFS).
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mi...@smith.net.au
\\ The race is long, and in the \\ msm...@freebsd.org
\\ end it's only with yourself. \\ msm...@cdrom.com
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Eivind Eklund
> > The only disadvantage that I can see is that the organization depends
> > utterly on the network and the fileserver. I think that any organization
> > that depends heavily on networking is stuck with this anyway.
>
> Indeed. You can address some of the performance issues with dataless,
> rather than diskless, workstations (local OS copy, local config
> replicated on a regular basis from a master server, apps and user data
> mounted via NFS).
With Coda coming up, it should be possible to do this configuration
more easily, using a local disk as a filesystem-managed cache. One of
the great advantages of Coda. (It will especially be an advantage if
you can turn off the disconnected operation support in Coda; I suspect
you can.)
Eivind.
Robert Watson
> Indeed. You can address some of the performance issues with dataless,
> rather than diskless, workstations (local OS copy, local config
> replicated on a regular basis from a master server, apps and user data
> mounted via NFS).
I personally prefer an almost-diskless-workstation. That is, one that has
a local disk but uses it only to bootstrap the boot process, and then for
swap/cache space. With an on-disk cache with Coda or AFS, things perform
very reasonably.
I have not had a chance to try to set up one of these using Coda, but I
might get around to it in a few weeks (once 5.0 of Coda is out). Coda is
not ready for production use yet, but we're getting there. Given the
success of such arrangements over AFS, I would anticipate that Coda could
handle it quite well. The only problem with the arrangement may be the
requirement for setuid binaries locally on workstation disks.
Multiplatform distributed file systems with their own
authentication/authorization scheme are not really compatible with the
concept of a setuid binary. So one has the choice of eliminating setuid
binaries (quite reasonable on a diskless x workstation -- no need for mail
delivery, local password changing, etc, assuming we get /proc in good
enough shape).
For the uninitiated on the list, http://www.coda.cs.cmu.edu/ is a good
source of information.
Robert N Watson
rob...@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C
Carnegie Mellon University http://www.cmu.edu/
TIS Labs at Network Associates, Inc. http://www.tis.com/
SafePort Network Services http://www.safeport.com/
Jason C. Wells
>> Jason Wrote:
>> Sometime ago I asked folks about NC's. Now I am back. Once again I am
>> armed with just enough info to be dangerous.
>
>Flee!
:)
>> It seems that running diskless has a serious advantage of using the same
>> disk space for all of the programs that all the users need. 100baseT can
>> compete with UW-SCSI bit for bit on bandwidth.
>
>No it can't. And NFS doesn't compete for latency. But many users
>don't need that sort of filesystem throughput.
If 100 Mbps => 80 Mbps then 100bT is as good or better than UW-SCSI on
bandwidth. This is what I based my statement on. It appears that I have a
concept error somehow. The numbers look right to me. Can someone steer me
straight?
Thanks for the insight from all who replied. I sent that email some time
ago. Is the list only now receiving it?
Catchya Later, | UW Mechanical Engineering
Jason Wells | http://weber.u.washington.edu/~jcwells/
Jamie Bowden
> >No it can't. And NFS doesn't compete for latency. But many users
> >don't need that sort of filesystem throughput.
>
> If 100 Mbps => 80 Mbps then 100bT is as good or better than UW-SCSI on
> bandwidth. This is what I based my statement on. It appears that I have a
> concept error somehow. The numbers look right to me. Can someone steer me
> straight?
SCSI measures throughput in Megabytes/s, not Megabits/s.
Jamie Bowden
--
Systems Administrator, iTRiBE.net
If we've got to fight over grep, sign me up. But boggle can go.
-Ted Faber (on Hasbro's request for removal of /usr/games/boggle)
Jamie Bowden
> On Mon, 30 Nov 1998, Jason C. Wells wrote:
>
> > >No it can't. And NFS doesn't compete for latency. But many users
> > >don't need that sort of filesystem throughput.
> >
> > If 100 Mbps => 80 Mbps then 100bT is as good or better than UW-SCSI on
> > bandwidth. This is what I based my statement on. It appears that I have a
> > concept error somehow. The numbers look right to me. Can someone steer me
> > straight?
>
> SCSI measures throughput in Megabytes/s, not Megabits/s.
And as a note I missed the first time, UW is 40MB/s, not 80MB/s.
Christopher R. Bowman
>On Sun, 29 Nov 1998, Mike Smith wrote:
>
>>> Jason Wrote:
>>> Sometime ago I asked folks about NC's. Now I am back. Once again I am
>>> armed with just enough info to be dangerous.
>>
>>Flee!
>
>:)
>
>>> It seems that running diskless has a serious advantage of using the same
>>> disk space for all of the programs that all the users need. 100baseT can
>>> compete with UW-SCSI bit for bit on bandwidth.
>>
>>don't need that sort of filesystem throughput.
>
>If 100 Mbps => 80 Mbps then 100bT is as good or better than UW-SCSI on
>bandwidth. This is what I based my statement on. It appears that I have a
>concept error somehow. The numbers look right to me. Can someone steer me
>straight?
Uh, where does 80Mbps come from? SCSI is 5 Mhz, Fast SCSI is 10Mhz, Ultra
is 20
Mhz, times 1 byte for Narrow or 2 bytes for Wide. So Ultra and Wide SCSI
should be 40 MByes/sec or 320 Mbps not 80Mbps. Maybe you are thinking U2W
which is 80 MBps or 640Mbps. So 100BTX isn't better than UltraWide SCSI.
Of course this all ignores transaction overhead, packet overhead, inter packet
space and realistic models of the latencies and bandwidths of the devices on
the other end. It is just a rough theoretical max throughput.
--------
Christopher R. Bowman
c...@ChrisBowman.com
http://www.ChrisBowman.com/
Mike Smith
> >> disk space for all of the programs that all the users need. 100baseT can
> >> compete with UW-SCSI bit for bit on bandwidth.
> >
> >No it can't. And NFS doesn't compete for latency. But many users
> >don't need that sort of filesystem throughput.
>
> If 100 Mbps => 80 Mbps then 100bT is as good or better than UW-SCSI on
> bandwidth. This is what I based my statement on. It appears that I have a
> concept error somehow. The numbers look right to me. Can someone steer me
> straight?
Mb != MB. Wide SCSI at 40MHz gives 80MB/sec. 100Mbps ethernet may
give you as much as 9MB/sec over NFS (if you're very lucky).
> Thanks for the insight from all who replied. I sent that email some time
> ago. Is the list only now receiving it?
No, I'm just working through the backlog that a week at Comdex built
up, and attacking some more of my outstanding backlog.
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mi...@smith.net.au
\\ The race is long, and in the \\ msm...@freebsd.org
\\ end it's only with yourself. \\ msm...@cdrom.com
To Unsubscribe: send mail to majo...@FreeBSD.org
Benedikt Stockebrand
> Of course this all ignores transaction overhead, packet overhead, inter packet
> space and realistic models of the latencies and bandwidths of the devices on
> the other end. It is just a rough theoretical max throughput.
And a server usually serves multiple clients. Even on a switched net
all this traffic has to go through a single 100 Mbps link between
switch and server.
This doesn't sound like a problem since most clients would spend
little of their time on disk/network I/O. But as soon as some of them
start to swap over the net this is a pain in the behind for everyone...
So long,
Ben
--
Benedikt Stockebrand Adimus Beratungsgesellschaft für System-
System Administration & Design, und Netzwerkadministration mbH & Co KG
IT Security, Remote System Mgmt Universitätsstr. 142, 44799 Bochum
Opinions presented are my own. Tel. (02 34) 971 971 -2, Fax -9