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é