Good points. I did not mention your #5 because it affects shared DASD too and was trying to contrast NFS and shared disk.
-- R; <>< Rick Troth Velocity Software http://www.velocitysoftware.com/ On Tue, Dec 14, 2010 at 10:12, Patrick Spinler <[email protected]> wrote: > On 12/14/2010 07:47 AM, Richard Troth wrote: >> >> Having just recommended NFS, I must respond to this question. YES, >> there are reasons why one might NOT want to use it. >> >> NFS is my first choice for shared RW storage or for any shared storage >> where you don't have a hardware sharing option. Caleb can share the >> disks at the HW level, so that is preferred. >> >> So why or when would one not want to go NFS? >> >> #1 - NFS firstly requires the network. The sharing systems cannot >> operate independently. (They cannot be isolated. Sometimes people >> isolate systems. Lots of reasons for that; do I need to enumerate? >> And don't get me started about port-grained access controls in >> switches and VLANs.) The requirement for the network also affects the >> sequencing at startup. Your NFS-resident content cannot be there >> until your network is fully operational. >> >> #2 - NFS means that one server has to "own" the data. That one server >> becomes another single point of failure. Even apart from failure, >> access times are different on all the other systems so you may find >> performance numbers out of balance. "It depends." >> >> #3 - (related to #2) NFS and NIS historically are the two services >> which can lock-up a system tighter than anything else. If the hosting >> NFS server goes away, or if there is some other problem between there >> and the client(s), then the client(s) are stuck until things are >> restored. >> > > #4 - Security issues. While there are options in NFSv4 protocol to do > secure authentication (and I believe, secure transmission) NFS defaults are > pretty open, both with regard to authentication and transmission. > > #5 - System UID/GID numbers. This is not a bad thing to do anyway, but it is > something to be aware of. Running NFS will force you to keep your UID and > GID numbers coordinated across all systems and accounts that access that > storage. Best to just set up a LDAP service and keep all your accounts in > sync everywhere. (Be aware that different unix like OS's default common > service accounts like apache to different values -- problems here) > > BTW -- to partially alleviate issue #3, we've moved to using our automounter > to mount all of our NFS storage on every client that needs it. It's not a > complete fix, but it helps a lot. > > I really really wish that there was a unix network filesystem that combined > e.g. AFS's reliability, client caching, distributed redundancy and secure > authentication with NFS's ubiquitousness, UNIX style security semantics and > ACL's. IMHO all the network filesystems out there have significant > drawbacks. > > -- Pat > > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
