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

Gé Weijers ge at weijers.org
Wed Jul 11 21:15:29 UTC 2012


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.
>
> --
>   Les Mikesell
>      lesmikesell at gmail.com
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos



-- 
Gé



More information about the CentOS mailing list