In a message dated: Tue, 15 Feb 2000 23:44:00 EST
Benjamin Scott said:
>On Tue, 15 Feb 2000, Derek Martin wrote:
>> Ben, PHILISOPHICALLY I agree with you, but PRACTICALLY speaking the
>> problem is that NFS doesn't guarantee that there will be no FS corruption
>> if you use the soft option. This is a Bad Thing.
>
> Hmmmm, by filesystem corruption, do you mean actual damage to the filesystem
>structure itself, or simply lost user data? I've never had any *serious*
>problems with "soft" NFS on Linux. Now, if a connection is lost of course the
>program won't be able to complete the I/O it was trying, but that'll happen
>regardless. And some programs actually check the result of their I/O. :)
I believe the problem with the 'soft' option is one of greater potential for
lost user data. Using 'hard' allows the client to persist until the server
comes back. In theory this is a good thing, though, as Derek pointed out, in
reality it too can cause problems. What if you're trying to move a filesystem
from one server to another? You essentially have no choice but to reboot all
the clients, since the hard option will hang them, and when the fs comes back
on line, they'll get "Stale NFS Filehandle" errors.
NFS is absolutely the worst possible solution...except for all the rest :)
> This may have changed with the kernel NFS driver, though. While the
>usermode NFS driver may have been slower, I really preferred the idea of
>keeping NFS in userland where it can't screw up the rest of the system.
While I agree with that, with an NFS server you normally want the best
performance possible (keep in mind, I'm talking about large environments, not
your typical home use situation). Placing nfsd into kernel space dramatically
improves performance over keeping it in userland (this is how Network
Appliance is able to serve NFS so fast).
> And as far as NFS on Solaris goes -- *barf*! For the company that invented
>the thing, Sun does a damn poor job of implementing it. :-(
NFS on Solaris isn't that bad. I've heard a lot about people complain about
it, but I've never seen a huge problem. Their implementation seems a whole
lot better than the other vendors out there. The *only* place where I see
Linux as having an advantage is in the exports options. Linux provides a lot
more flexibility and control over how things get exported and to whom than any
other Unix I've ever seen, including Solaris. Unfortunately, most of our NFS
is done from NAC boxes, which use a stripped down version of SunOS4.1.4 as
their kernel, and therefore the NFS exports options are restricted to that
which exists in the BSD world. This drastically limits the amount of control
you have. For instance, I use NIS netgroups extensively to control what
client systems can access certain NFS exported filesystems. I can export
'access=netgroup_name' but for the 'root' option, I have to export
'root=a,list,of,system,names', which I think is ridiculous!
>> Avoid NFS at all cost, if you can.
>> ^^^^^^^^^^
> That's the kicker, isn't it? Samba and SMB actually seem pretty good, as
>network file systems go (despite the fact that the protocol is rather poorly
>documented and the Microsoft implementations suck (as usual)), but it doesn't
>support any kind of idea of Unix permissions. :-(
I think NFS is a whole lot better than SMB, regardless of who's implimenting
SMB. SMB/NetBIOS/NetBEUI are just really horrible protocols (all based upon
the really old DECNET) Have you read any of the Samba books that explain how
these protocols work? If you think NFS is bad, then you likely haven't. If
you had, you'd be appalled! :)
>> Have you tried afs or coda? Anyone?
>
> I haven't actually *tried* either of these, but from what I've read, aren't
>they huge overkill for many situations? All I want to do is share some files
>with other machines on my LAN; I don't need a distributed, caching,
>high-availability, offline-capable, binds-the-world-together-and-cures-cancer
>filesystem. :-)
>
> Still, I suppose "too much" is better then "not enough". Another thing to
>add to my to-do list... >sigh< :)
Well, keep in mind that todays corporate culture heavily utilizes laptops
which now come with 8 and 13 GB harddrives. People like managers,
sales/marketing, executives, etc., all travel quite frequently. A
distributed, caching fs technology would solve a lot of problems for both
them, and us IT people. It would allow for the instantaneous sync'ing of the
laptop with the network once it were re-connected with the local LAN, and
allow the backup of the laptop data! This is a huge win for many people.
Unfortunately, we're stuck with the limitations of NFS because it's an
industry standard, and there's no demand for anything else :(
--
Seeya,
Paul
----
Doing something stupid always costs less (up front) than doing
something intelligent.
Bean counters are *always* wrong!
A conclusion is simply the place where you got tired of thinking.
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
**********************************************************
