Gé Weijers wrote: > This is likely to be a bug in RHEL5 rather than one in RHEL6. RHEL5 > (kernel 2.6.18) does not always guarantee that the disk cache is > flushed before 'fsync' returns. This is especially true if you use > software RAID and/or LVM. You may be able to get the old performance > back by disabling I/O barriers and using a UPS, a RAID controller that > has battery backed RAM, or enterprise-grade drives that guarantee > flushing all the data to disk by using a 'supercap' to store enough > energy to complete all writes. > > Gé > > On Wed, Jul 11, 2012 at 9:49 AM, Les Mikesell <lesmikesell at gmail.com> > wrote: >> On Wed, Jul 11, 2012 at 11:29 AM, Colin Simpson >> <Colin.Simpson at iongeo.com> wrote: >>> >>> But think yourself lucky, BTRFS on Fedora 16 was much worse. This was >>> the time it took me to untar a vlc tarball. >>> >>> F16 to RHEL5 - 0m 28.170s >>> F16 to F16 ext4 - 4m 12.450s >>> F16 to F16 btrfs - 14m 31.252s >>> >>> A quick test seems to say this is better in F17 (3m7.240s on BTRFS but >>> still looks like we are hitting NFSv4 issues for this but btrfs itself >>> is better). >> >> I wonder if the real issue is that NFSv4 waits for a directory change >> to sync to disk but linux wants to flush the whole disk cache before >> saying the sync is complete. Thanks, Les, that's *very* interesting. Based on that, I'm trying again, as I did back in March, when I filed the original bug (which I think meant we were doing it in 6.0 or 6.1), but async on both server and client, and getting different results. >> Ge, sorry, but it hit us, with the same configuration we had in 5, when we tried to move to 6. And please don't top post. mark