In a message dated: Tue, 20 Mar 2001 23:14:06 EST
Benjamin Scott said:
>On Tue, 20 Mar 2001, Paul Lussier wrote:
>> SMB is inherently buggy and incredibly slow.
>
> SMB has higher overhead and an incredibly crufty design. But in some cases,
>SMB can actually be quite a bit faster than NFS. For example, with oplocks,
>the client can cache file accesses locally, greatly reducing network traffic.
I don't know how much it reduces traffic, but I tend to doubt that it does so
enough to matter on a large network.
>> Additionally, SMB is non-routable, where as NFS just rides on top of IP.
>
> This is incorrect. SMB, as implemented in Linux, uses NetBIOS-over-IP,
>which is as routable as anything-else-over-IP. NetBEUI is not routable, but
>until very recently, NetBEUI wasn't even possible on Linux.
I don't believe this is accurate, it's 6:00 in the morning right now, and I
have not had either food or coffee, therefore I won't argue this point at this
time. I do, however, reserve the right to argue it later, provided my foot
doesn't get in the way ;)
>> You can play some tricks with Windows networking, but that's really
>> placing WINS over IP, not SMB.
>
> WINS (Windows Internet Name Service) is Microsoft's name for NBNS (NetBIOS
>Name Service), which maps NetBIOS names to IP addresses -- similar in concept
>to DNS. Saying using WINS invalidates SMB is like saying using DNS
>invalidates NFS. :-)
I wasn't saying that WINS invalidates SMB. I was saying that some things to
do with Windows Networking can be routed, i.e. WINS, if placed on top of IP.
Though if your name service is not working correctly, I contend that your
access to remote systems and the file systems contained therein will be made
incredibly difficult; the more so if you have users who don't know an IP
address from a mailing address :)
>> If you really want the low-down on how ugly SMB is ...
>
> SMB may be ugly, but on Linux, in the past, it has actually been better
>supported in the kernel than NFS! For a long time, Linux's NFS locking was
>broken, which could cause *data loss*. I'll take "slow" over "fast but loses
>data" any day. :-)
Exactly when was that? And does it matter, here and now? Current day, NFS is
well supported, as is SMB. Currently, NFS is faster and more efficient than
SMB. A long time ago, or in the past is irrelevant.
> Keep in mind that NFS uses *blind host trust relationships*. A hashed
>password might not be a very secure authentication method, but it's a damn
>sight better then simply assuming everything from a given IP is trusted! :-)
On an insecure network, or one where users are allowed free reign,
then yes, I might agree with that. However there are things you can do,
even with host-based authentication that can make life difficult enough to
keep the average user from bothering.
However, I contend that if you're going to base your network security on the
Window's encryption scheme, that you've made life easy enough for anyone that
there's little difference in that level of security and that of blind
host-based security.
> Also: User-based authentication is very often a feature, not a bug.
I never said it was a bug. Actually, I thought I mentioned that this was one
of the few things I thought Microsoft got right. They just completely
invalidated it by using such a lousy encryption algorithm.
>On Tue, 20 Mar 2001 [EMAIL PROTECTED] wrote:
>> Other SMB bummers:
>>
>> 1. It's stateful more intensely so than NFSv3 or NFSv4 will
>> ever be.
>
> I consider this a feature, not a bug. Unix file I/O is a stateful thing.
>Trying to make it stateless is, IMNSHO, an error. :-)
I disagree. At least with NFS, if a server or file system goes away, provided
you have the environment set up with soft,intr mounts, any given client can
just go on working. Try taking a file server out from under a Windows client
and see how long it takes the user to realize they need to reboot!
>> 3. Browse lists suck.
>
> Don't do that, then! If you use "Broadcast" or "Hybrid" mode, SMB will
>suck. If you use a 2400 modem without error correction, NFS will suck, too.
>Use WINS with all nodes in "Peer" mode, and get rid of all that crap. :-)
How exactly do you do that? (I ask, because I don't know, not because I'm
trying to be smart-a$$ :)
>> I was wondering if you have looked into NFS v4 yet? I haven't, but it
>> might have the per-user authentication you are interested in.
>
> Admittedly, I have not. And while I haven't checked up on NFS on Linux in
>awhile, last I heard, NFSv4 was a *long* ways away. :-)
Well, from what I've heard, NFSv4 is at least a year off. For Linux though, I
wonder how long it will take. The only people working on the Linux
implementation is UMichigan at CITI. Which is all great and wonderful, but
without a large backer, I doubt many enterprises will be interested in making
the switch to something so critical. Using a mail client (pine), an IMAP
server (UW-IMAP), or an ftp server (WU-FTP) based on a term-paper is one
thing. To have your entire environment, the crown jewels of your company,
dependant upon one with no one who *really* knows what they're doing is
another. I'm not slighting the caliber of the UMichigan students or
researchers, nor am I saying that large companies like Sun have better
programmers. Rather, I'm saying that corporate America like to know that
there's a respectable name behind a product. Currently there is no one behind
NFSv4.
Additionally, GFS and ReiserFS are making great advances in there code, and a
lot of people are very interested in these 2 file systems. Both also have
well known and respected names supporting them now.
And what effect will IBM's distributed lock management have?
Etc. etc, and, of course, etc. :)
Currently there are just way too many unknowns right now to honestly or
accurately predict when or *if* NFSv4 will be ready for use.
--
Seeya,
Paul
----
"I always explain our company via interpretive dance.
I meet lots of interesting people that way."
Niall Kavanagh, 10 April, 2000
If you're not having fun, you're not doing it right!
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
