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@gmail.com wrote:
On Wed, Jul 11, 2012 at 11:29 AM, Colin Simpson Colin.Simpson@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@gmail.com _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos