在我的情况下，我想在所有glusterfs完全启动后启动remote-fs单元。 我的系统文件： glusterfs目标： node04:/usr/lib/systemd/system # cat glusterfsd.service [Unit] Description=GlusterFS brick processes (stopping only) After=network.target glusterd.service [Service] Type=oneshot ExecStart=/bin/true RemainAfterExit=yes ExecStop=/bin/sh -c "/bin/killall –wait glusterfsd || /bin/true" ExecReload=/bin/sh -c "/bin/killall -HUP glusterfsd || /bin/true" [Install] WantedBy=multi-user.target remote-fs目标： node04:/usr/lib/systemd/system # cat remote-fs.target [Unit] Description=Remote File Systems Documentation=man:systemd.special(7) Requires=glusterfsd.service After=glusterfsd.service remote-fs-pre.target DefaultDependencies=no Conflicts=shutdown.target [Install] WantedBy=multi-user.target 好的，所有Gluster守护进程开始成功，我想通过NFS安装Gluster文件系统，但Gluster的NFS共享在glusterfs.service启动后不会立即准备好，但是几秒钟后，所以通常remote-fs甚至无法安装它，和After指令。 我们来看看日志： Apr […]
我正在计划我的新的共享存储基础设施的小型networking服务器场。 所以我跑了很多NAS文件系统的testing。 通过这样做，我得到了一些意想不到的结果，并想知道这里有人能否证实这一点。 简而言之：对于小文件写入，Samba比NFS和GlusterFS快得多。 在这里，我做了：我运行了一个简单的“rsync基准”与大量的文件来比较小文件的写入性能。 为了更容易的再现，我现在重新运行了当前的wordpress tar.gz的内容。 GlusterFS复制2： 32-35秒 ，高CPU负载 GlusterFS单机： 14-16秒 ，CPU负载高 GlusterFS + NFS客户端： 16-19秒 ，CPU负载高 NFS内核服务器+ NFS客户端（同步）： 32-36秒 ，CPU负载非常低 NFS内核服务器+ NFS客户端（asynchronous）： 3-4秒 ，非常低的CPU负载 Samba： 4-7秒 ，CPU负荷中等 直接磁盘： <1秒 我绝对没有桑巴大师（我认为我最后一次与samba 2.x联系），所以我没有在这里优化任何东西 – 只是开箱即用的configuration（debian / squeeze包）。 我唯一添加了“同步总是=是”，这应该是写后强制同步（但看到这些结果..）。 没有它，testing在哪里约1-2秒快。 在同一台机器上运行的所有testing（自行安装的是NAS导出），所以没有networking延迟 – 纯协议性能。 边节点：作为文件系统，我使用ext4和xfs。 以上结果与ext4。 xfs可以达到40％（更less的时间）。 这些机器是EC2 m1.small实例。 NAS导出在EBS卷上，临时磁盘上的源（解压缩的tar）。 所以现在我们走了：有人可以向我解释为什么桑巴速度如此之快吗？ 另外：在同步模式下，内核服务器的NFS性能是否可怕（由GlusterFS NFS服务器胜出）？ 任何想法如何调整？ 谢谢，L