[CentOS] Fwd: Bug 800181: NFSv4 on RHEL 6.3 over six times slower than 5.8

Wed Jul 11 21:29:55 UTC 2012
m.roth at 5-cent.us <m.roth at 5-cent.us>

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.
> 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.