Re: Access to hard drives over a network
- From: kludge@xxxxxxxxx (Scott Dorsey)
- Date: 25 Oct 2008 20:36:52 -0400
Randy Yates <yates@xxxxxxxx> wrote:
kludge@xxxxxxxxx (Scott Dorsey) writes:
Easy for whom? A certified IT administrator? Yeah, MAYBE.
You start the server and client daemons, t
Huh? There IS no client daemon. Rather, you mount the remote filesystem
using either the mount command or the /etc/fstab table. If you use the
/etc/fstab method (which is the most common), you must make decisions on
the mount options, the dump option, and the filesystem check.
With SMB you get the client daemon, with NFS you don't, and everything is
built into the kernal.
Thing is, the machines are shipped with everything built into the kernal,
you don't need to add this stuff as a layered product anymore or
anything.
And yes, you can mount by hand from the terminal or you can put it in
/etc/fstab or /etc/dfstab and let the OS do it on boot time. Or you
can use the automounter and have the automounter mount them automatically
only when they are needed (which is the most convenient thing to do as
long as you don't mind a little latency the first time you access a remote
file).
The mount options include access permisions, read block sizes, write
block sizes, port number, hard mounting options, and a myriad of other
options too long to go into here.
Yup, and today you can just leave them all set to the defaults. Back in
the ages of Version 2 NFS, you often had to fiddle with that stuff, and
making SGI products talk to anybody else's NFS implementation was a major
exercise in frustration (aided by the SGI development guys on the phone
telling you how much better their NFS implementation was and how all your
problems are Sun's fault).
It's not like that any more! You just use the defaults and it works!
On the server side, there really isn't just one "server" involved in
serving NFS files but three: rpc.mountd, nfsd, and rpc.rquotad.
You don't really need quotad if you aren't running quotas. And depending
on your implementation you might need lockd. And back in the old days
you'd usually have to turn the portmapper on because it wasn't running by
default.
These days you just turn everything on when you configure the system
and it all just works. With NetBSD, the default rc scripts look for
the relevant configuration files and start up nfs if they notice that
you are sharing anything. It's all seamless (until it breaks).
Then you decide the actual paths you want to service out, who can
use them, and what permissions they can use them with, in the
/etc/exports file.
Yup.
And I haven't even gotten into problems that can happen with NFS, such
as when the user id on one computer doesn't match the user id on
another.
Oh yeah... REAL SIMPLE.
If you think this is bad, try using SMB with remote authentication!
Honestly, NFS has a lot of stuff going on underneath, but most people
don't need to see that, and the default configurations all work pretty
well unless you're trying to talk to something weird. There was a day
when people setting up NFS had to spend a lot of time worrying about
block sizes and rebuilding the kernal, but not any more.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
.
- Follow-Ups:
- Re: Access to hard drives over a network
- From: Randy Yates
- Re: Access to hard drives over a network
- References:
- Access to hard drives over a network
- From: robertjwarren
- Re: Access to hard drives over a network
- From: Andre Majorel
- Re: Access to hard drives over a network
- From: Scott Dorsey
- Re: Access to hard drives over a network
- From: Randy Yates
- Access to hard drives over a network
- Prev by Date: Re: Mixing and tracking at 96k verses 44k??
- Next by Date: Re: Access to hard drives over a network
- Previous by thread: Re: Access to hard drives over a network
- Next by thread: Re: Access to hard drives over a network
- Index(es):
Relevant Pages
|