Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm planning to deploy some kiosk computers and would like to leave them with a small pendrive as boot disk, keeping the rest at an easy to back up server, ala LTSP.

Right now I'm pondering two options. An NFSed /home/, or a local copy of ~/ copied on login, rsynced on logout.

My fears are that working with files might get too slow, or my network might get clogged.

share|improve this question
    
Could you please replace "safe" with another word that's less related to security? Maybe feasible merriam-webster.com/dictionary/feasible ? –  Cristian Ciupitu Jun 4 '09 at 2:42
    
A slight sense of déja vu. It's not the exact same thing, but it's an interesting thread they've got there. hardware.slashdot.org/story/09/06/23/1823201/… –  voyager Jun 23 '09 at 22:52

9 Answers 9

up vote 20 down vote accepted

I use NFS for my home directories in our production environment. There are a couple of tricks.

  1. Don't NFS mount to /home - that way you can have a local user that allows you in in the event that the NFS server goes down. We mount to /mnt/nfs/home

  2. Use soft mounts and a very short timeout - this will prevent processes from blocking forever.

  3. Use the automounter. This will keep resource usage down and also means that you don't need to worry about restarting services when the NFS server comes up if it goes down for some reason.

    auto.master:
      +auto.master
      /mnt/nfs /etc/auto.home --timeout=300
    
    auto.home
       home -rw,soft,timeo=5,intr      home.bzzprod.lan:/home
    
  4. Use a single sign-on system so you don't run into permission related issues. I have an OpenLDAP server.

share|improve this answer
    
I've always found the automounter horribly unreliable and prone to locking up, especially if the NFS server goes down. If you mount to /mnt/nfs/home, is that where you set the user's home in /etc/passwd? –  pjc50 Oct 14 '09 at 14:16
1  
Well, using /etc/passwd and NFS mounting home dirs is a bad idea, as you have to keep the UID and GIDs in sync - use something like OpenLDAP, but yes, the user's home dir is set to /mnt/nfs/home/username. –  Aaron Brown Dec 8 '09 at 15:06

http://www.howtoforge.com recently posted an article on using GlusterFS as a NFS replacement/alternative, you may want to check it out.

http://www.howtoforge.com/creating-an-nfs-like-standalone-storage-server-with-glusterfs-on-debian-lenny

Here is a short description of why its a good 'feasible' alternative to NFS, from the GlusterFS project page http://www.gluster.org/:

"GlusterFS self-heals itself on the fly. There is no fsck. Storage backend is accessible directly as regular files and folders (NFS style). With replication enabled, GlusterFS can with-stand hardware failures."

More information can be found in the project documentation.

Also, another nice thing about using GlusterFS is if you need more space on your SAN you just add another storage brick (server node) and you are able to scale/grow your storage in parrallel when there is need.

Hope this helps or at least helps point you in the right direction!

share|improve this answer

Be careful with the soft mounts! Soft mounting an NFS filesystem means IO will fail after a timeout occurs. Be very sure that is what you want on users' home directories! My guess is you don't. Using a hard mount on home directories in combination with the intr option feels a lot safer here.

Hard will not timeout: IO operations will be retried indefinitely. The intr option makes it possible to interrupt the mounting process. So if you mount the export and experience a failure, the hard-mount will lock your session. The intr option will make it possible to interrupt the mount, so the combination is pretty safe and ensures you will not easily lose a user's data.

Anyway, autofs makes this all even easier.

share|improve this answer

I lot of places I have worked use NFS mounted home directories. There usually isn't a huge difference in performance (and kiosk users are probably a bit less demanding than developers who know how to get hold of their local IT guy). One problem I have seen is what happens when I'm logged into a Gnome desktop and the NFS server goes away for whatever reasons. Things get real unresponsive.

share|improve this answer

The one thing to note is that when the NFS server is out - your mounts will freeze - doing a soft mount will not block so the "freeze" itself can be avoided, however that will not fix the problem of home directories as without a home directory, the user is screwed anyway.

Even when the NFS server recovers, unless you do something about it, the freeze problem will remain - you'll have to kill the process on the mounting machine, and remount. The reason for this is that when the NFS server comes back up, it assigned a different fsid - so you can at least fix this problem by hard-coding the fsids on the NFS server, for example...

#. Home Directories
/usr/users \
  192.168.16.0/22(rw,sync,no_root_squash,fsid=1) \
  192.168.80.0/22(rw,sync,no_root_squash,fsid=1)

#. Scratch Space
/var/ftp/scratch \
  192.168.16.0/22(rw,async,no_root_squash,fsid=3) \
  192.168.80.0/22(rw,async,no_root_squash,fsid=3) \
  172.28.24.151(rw,async,root_squash,fsid=3)

The exports(5) man page states...

fsid=num
          This option forces the filesystem identification portion of the file handle
          and  file attributes used on the wire to be num instead of a number derived
          from the major and minor number of the block device on which the filesystem
          is  mounted.   Any 32 bit number can be used, but it must be unique amongst
          all the exported filesystems.

          This can be useful for NFS failover, to ensure that  both  servers  of  the
          failover  pair use the same NFS file handles for the shared filesystem thus
          avoiding stale file handles after failover.

...While that indicates that as long as the major/minor numbers do not change (which they usually don't, except for when you're exporting SAN/multipath volumes, where the may change), I've found that we've completely removed the problem - i.e., if the NFS server comes back - the connection has been restored quickly - I still really don't know why this has made a difference for devices such as /dev/sdaX for example.

I should now point out that my argument is largely anecdotal - it doesn't actually make sense why it has fixed the problem, but it "seems" to have fixed it - somehow - there are probably other variables at play here that I've not yet discovered. =)

share|improve this answer
    
Are you sure about this "random" fsid used by the server? –  Cristian Ciupitu Jun 4 '09 at 2:33
    
Hi Cristian - I've tried to explain above - but I can't fully explain the behavior with respect to the man page description of the flag. Have you tried it and seen otherwise? –  Xerxes Jun 4 '09 at 3:26

Some general advice that will apply no matter which network filesystem you adopt: many programs cache data in the user's home directory, which usually does more harm than good when the home directory is accessed over a network.

These days, you can tell many programs to store their caches elsewhere (e.g., on a local disk) by setting the XDG_CACHE_HOME environment variable in a login script. Lots of programs (e.g., Firefox) still require manual configuration, however, so you will probably have to do some extra work to identify and configure them in a uniform manner for all your users.

share|improve this answer
    
+1 I've had performance problems with Google Chrome and NFS home dirs. fixed it by moving Chrome's working directories back to the local system, then placing a symlink from the NFS home dir (where Chrome expects to find the dirs), back to the local directory. There may be a better way of doing what I've done, but it solved the problem for me. –  Bryan Mar 9 '12 at 13:37
    
Bryan (march 9) left a good partial answer, however, I want to elaborate on this issue. Please do... Thank you.. How did you move the working directories to the local machine, and place symlinks. –  Jason Oct 4 '12 at 1:59
    
Also look into the XDG_RUNTIME_DIR described for Dconf database location at: developer.gnome.org/dconf/unstable/dconf-overview.html –  JKnight Jul 1 at 21:17

I use an NFSed home and it works fine. but you must make sure the network is fast enough and that it will never be down.

share|improve this answer

On a practical basis, NFS performs well for home directory if there's a 100mbit switched network or better. For more then 10-20 kiosks, the server should have gigabit connectivity. You won't win performance contests, but things like Firefox and Open Office will work okay.

Copying in the home directory will be a major pain in term of delays at login (on a 100mbit network that's max 12MB/s. A 100MB home directory is close to 10 seconds.) Rsync will thrash you syncing web browser cache... 10 minutes and 500 files hurt.

share|improve this answer

Have a look at cachefilesd. I haven't used it myself, but it looks promising.

The cachefilesd daemon manages the caching files and directory that are that are used by network filesystems such a AFS and NFS to do persistent caching to the local disk.

Also, don't forget to tune the rsize and wsize parameters and use Jumbo frames if possible.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.