On Tue, Mar 5, 2013 at 1:57 PM, Torbj?rn Thorsen <torbjorn at trollweb.no> wrote: > On Fri, Mar 1, 2013 at 7:01 PM, Brian Foster <bfoster at redhat.com> wrote: >> On 03/01/2013 11:48 AM, Torbj?rn Thorsen wrote: ... > A degraded loop device without an open fd will be fast after a toggle > of write-behind. > However, it seems that an open fd will keep the loop device slow. > I've only tested that with Xen, as that was the only thing I had with > a long-lived open fd to a loop device. > >> Also, what gluster and kernel versions are you on? > > # uname -a > Linux xen-storage01 2.6.32-5-xen-amd64 #1 SMP Sun May 6 08:57:29 UTC > 2012 x86_64 GNU/Linux > > # dpkg -l | grep $(uname -r) > ii linux-image-2.6.32-5-xen-amd64 2.6.32-46 > Linux 2.6.32 for 64-bit PCs, Xen dom0 support > > # dpkg -l | grep gluster > ii glusterfs-client 3.3.1-1 > clustered file-system (client package) > ii glusterfs-common 3.3.1-1 > GlusterFS common libraries and translator modules > I've now tested with a newer kernel, and I'm seeing pretty much the same thing there. # dpkg -l | grep $(uname -r) ii linux-image-3.2.0-0.bpo.4-amd64 3.2.35-2~bpo60+1 Linux 3.2 for 64-bit PCs After a while the loop device and Xen instance is slow, and profile tells me it's only seeing 4kb writes. Toggling the write-behind translator off and on again gets me back to the initial transfer rate. Contrary to what I have said earlier, this time I saw the transfer rate change on a running Xen instance. As far as I can tell, this means the transfer rate change also affects open fd-s to the loop device. I'll try filing a bug in the tracker that was mentioned in the -- Vennlig hilsen Torbj?rn Thorsen Utvikler / driftstekniker Trollweb Solutions AS - Professional Magento Partner www.trollweb.no Telefon dagtid: +47 51215300 Telefon kveld/helg: For kunder med Serviceavtale Bes?ksadresse: Luramyrveien 40, 4313 Sandnes Postadresse: Maurholen 57, 4316 Sandnes Husk at alle v?re standard-vilk?r alltid er gjeldende
