Slow XFS performance with write cache and default mount options

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello list!

I'm running F8/x86_64 on a reasonably new and fast machine and recently
I copied an 8GB directory (with about 90000 files) from one XFS
partition to another (on the same disk).  This took a *long* time -- I
believe around 50 minutes.  Then I deleted the directory from the
original partition and it took another 50-60 minutes.  That made me
google the issue a bit and I found something about disk write cache,
journaling file systems, and a relatively recent nobarrier mount
option.  So I did a simple test (copying an 800MB directory with ~4000
files) with all combinations of write cache and nobarrier mount option:

WRITE CACHE   MOUNT OPTIONS   COPYING TIME (800MB/4000 files)

  enabled        default      real    2m4.113s
                              user    0m0.160s
                              sys     0m3.200s

  enabled       nobarrier     real    0m51.482s
                              user    0m0.151s
                              sys     0m3.478s

 disabled        default      real    1m35.870s
                              user    0m0.172s
                              sys     0m3.282s

 disabled       nobarrier     real    1m9.233s
                              user    0m0.124s
                              sys     0m3.241s

This brings me to the following questions:

1) As far as I understand, the fastest combination (write cache enabled
+ nobarrier) is dangerous because of the possibility of file system
corruption on unexpected power failure.  The next one is write cache
disabled + nobarrier -- does this combination carry any similar dangers?

2) If no, is there any (performance or any other) reason to keep write
cache turned on?

3) Turning write cache off doesn't seem to be preserved after a
reboot.  Is there a kernel boot option for it?  If no, would it be a
good solution to put something like
hdparm -W0 /dev/sda
in /etc/rc.local?

4) Do other journaling file systems suffer the same performance penalty
through write cache + barrier?

Thanks,
Srdan

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux