On Mon, Sep 10, 2012 at 11:13:11AM +0200, Stephan von Krawczynski wrote: > If you have small files you are busted, if you have workload on the clients > you are busted and if you have lots of concurrent FS action on the client you > are busted. Which leaves you with test cases nowhere near real life. > I replaced nfs servers with glusterfs and I know what's going on in these > setups afterwards. If you're lucky you reach something like 1/3 of the NFS > performance. This is an informative debate. But I wonder, Stephan, how much of the bustedness you report is avoided by simply using NFS clients with Gluster. For my own purposes, Gluster (3.1.4) has performed well in production. And it's hardly an optimal arrangement. For instance, there's a public-facing FTP/SFTP server NFS mounting mirrored Gluster servers over a gigabit LAN. The FTP/SFTP server also re-exports the NFS Gluster shares via Samba, to a medium-sized office. Numerious files of a wide range of sizes continuously go in an out of this system from every direction. We haven't always run this way. It used to be the same setup, but with local storage on the FTP/SFTP/Samba server. Yet nobody since the switch to Gluster has so much as commented on the speed, and half of our staff are programmers who are not shy about critiquing system performance when they see it lagging. Now, when I tested Gluster for KVM - yeah, that doesn't work. And there are going to be environments in which file servers are far more stressed than ours. But since part of the slowness of Gluster for you is about the Gluster clients rather than servers - well, I'd like to see the NFS-client-to-Gluster test as comparison. Some here have reported it's faster. It's certainly in my own use case fast enough. Whit
