我打算部署一些电脑亭，并希望将它们作为启动磁盘放在一个小的硬盘驱动器上，其余部分保存在一个易于备份的服务器ala LTSP中 。
现在我正在思考两个select。 NFSed / home /或login时复制的本地副本，在注销时rsynced。
我担心的是，使用文件可能会变得太慢，或者我的networking可能堵塞 。
我在我们的生产环境中使用NFS作为我的主目录。 有几个技巧。
不要NFS挂载到/home – 这样你可以有一个本地用户，允许你在NFS服务器closures的情况下。 我们挂载到/mnt/nfs/home
使用软安装和一个非常短的超时 – 这将防止进程永远阻塞。
使用自动加载器 。 这样可以减less资源使用，也意味着当NFS服务器出现故障时，不必担心重新启动服务。
auto.master: +auto.master /mnt/nfs /etc/auto.home --timeout=300 auto.home home -rw,soft,timeo=5,intr home.bzzprod.lan:/home
使用单一login系统，以免遇到与权限相关的问题。 我有一个OpenLDAP服务器。
http://www.howtoforge.com最近发表了一篇关于使用GlusterFS作为NFSreplace/替代的文章，您可能想要查看它。
下面是GlusterFS项目页面http://www.gluster.org/为什么selectNFS的一个很好的“可行的”替代方法的简短描述：
“GlusterFS可以自行修复，不存在fsck，可以直接以普通的文件和文件夹（NFS风格）访问存储后端，启用复制function后，GlusterFS可以承受硬件故障。
更多信息可以在项目文档中find。
此外，使用GlusterFS的另一个好处是，如果您需要SAN上更多空间，只需添加另一个存储砖（服务器节点），并且在需要时可以并行扩展/扩展存储。
希望这有助于或至less有助于指出你在正确的方向！
小心软安装！ 软安装NFS文件系统意味着超时后IO将失败。 要确定这是你想要在用户的主目录！ 我的猜测是你没有。 在主目录中使用硬挂载与intr选项相结合在这里感觉更安全。
硬不会超时：IO操作将无限期重试。 intr选项可以中断安装过程。 所以，如果你挂载导出并遇到故障，硬盘将locking你的会话。 intr选项可以中断挂载，所以组合非常安全，并且确保您不会轻易丢失用户的数据。
无论如何，autofs使这一切更容易。
有一点需要注意的是，当NFS服务器不在时，你的坐骑将会冻结，软盘的安装不会被阻塞，因此可以避免“冻结”本身，但是这并不能解决主目录的问题，因为没有家目录，反正用户被拧紧了。
即使NFS服务器恢复，除非你做了一些事情，冻结的问题将保持 – 你将不得不杀死安装机器上的进程，并重新安装。 原因是，当NFS服务器恢复时，它分配了一个不同的fsid – 所以你至less可以通过硬编码NFS服务器上的fsid解决这个问题，例如…
#. 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)
exports(5)手册页状态…
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.
…虽然这表明只要主要/次要数字不会改变（除了当您导出SAN /多path卷，哪里可能会改变时），我发现我们已经完全消除了这个问题 – 也就是说，如果NFS服务器回来了 – 连接已经很快恢复了，我还是不知道为什么这对于像/dev/sdaX这样的设备有所不同。
我现在应该指出，我的观点很大程度上是轶事 – 为什么它解决了这个问题并没有什么意义，但是似乎已经解决了这个问题 – 不知何故 – 在这里我可能还有其他变数尚未发现。 =）
无论您采用哪种networking文件系统，一些常规build议将适用：许多程序将数据caching在用户的主目录中，当通过networking访问主目录时，这通常会带来更多的伤害。
现在，通过在login脚本中设置XDG_CACHE_HOME环境variables，您可以告诉许多程序将其caching存储在其他地方（例如本地磁盘上）。 许多程序（例如Firefox）仍然需要手动configuration，但是，您可能需要做一些额外的工作，以统一的方式为所有用户识别和configuration它们。
我工作过的很多地方使用NFS挂载的主目录。 性能通常没有太大的差别（对于知道如何获得本地IT人员的开发人员来说，信息亭用户的要求可能要低一些）。 我看到的一个问题是，当我login到Gnome桌面时，会出现什么情况，并且NFS服务器因为什么原因而消失。 事情得到真正的反应迟钝。
我使用NFSed家庭，它工作正常。 但是你必须确保networking速度足够快，而且永不停机。
在实际的情况下，如果有100mbit的交换networking或者更好的话，NFS可以很好地用于主目录。 对于更多10-20个信息亭，服务器应该具有千兆位连接。 你不会赢得性能竞赛，但是像Firefox和Open Office这样的东西可以正常工作。
复制到主目录将是一个主要的痛苦，在延迟login（在一个100MB的networking，最大12MB /秒，一个100MB的主目录接近10秒。）Rsync的将thrash你同步网页浏览器caching… 10分钟和500个文件受到伤害。
看看cachefilesd 。 我自己并没有使用它，但它看起来很有希望。
cachefilesd守护程序pipe理networking文件系统（如AFS和NFS）使用的caching文件和目录，以执行对本地磁盘的持久caching。
此外，请不要忘记调整rsize和wsize参数，并尽可能使用Jumbo帧。