xfs
[Top] [All Lists]

XFS write speed down

To: xfs@xxxxxxxxxxx
Subject: XFS write speed down
From: Jan Engelhardt <jengelh@xxxxxxxxxx>
Date: Thu, 29 Apr 2010 23:46:33 +0200 (CEST)
User-agent: Alpine 2.01 (LSU 1266 2009-07-14)
Hi,



Running 2.6.33.2, I am observing this 

used-xfs$ time ( tar -xf /dev/shm/linux-2.6.33.3.tar ; sync )
real    12m29.272s
user    0m0.196s
sys     0m3.028s
meta-data=/dev/md3               isize=256    agcount=32, agsize=11429117 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=365731739, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=32768, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0
/dev/md3 / xfs rw,relatime,attr2,nobarrier,noquota 0 0

# xfs_db -c frag -r /dev/md3
actual 917392, ideal 838246, fragmentation factor 8.63%
# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/md3             292585344  945559 291639785    1% /
# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md3             1462795884 701393616 761402268  48% /


What would cause XFS to go down in performance so much here? Did md3
collect too much dust already?
("sync" is not the problem; tar itself runs for over 7 minutes)
Here are some comparisons to other filesystems or use levels:


tmpfs$ time ( tar -xf /dev/shm/linux-2.6.33.3.tar ; sync )
real    0m1.453s
user    0m0.096s
sys     0m0.692s


fresh-ext4$ time ( tar -xf /dev/shm/linux-2.6.33.3.tar ; sync )
real    0m7.657s
user    0m0.096s
sys     0m1.208s
/dev/loop9 /mnt ext4 rw,relatime,barrier=1,data=ordered 0 0
(loopfile stored on md3)


fresh-xfs$ time ( tar -xf /dev/shm/linux-2.6.33.3.tar ; sync )
real    0m10.212s
user    0m0.172s
sys     0m1.616s
Loopfile also residing on md3.


used-btrfs$ time ( tar -xf /dev/shm/linux-2.6.33.3.tar ; sync )
real    0m25.077s
user    0m0.128s
sys     0m2.404s
This btrfs also runs on loop, and is stored on md3.

The machine is a

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
stepping        : 4
cpu MHz         : 1600.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est
tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow
vnmi flexpriority ept vpid
bogomips        : 5345.48
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


This 12 minute extraction is worse than a metadata intensive
copy on an even older box[1].

[1] http://lkml.org/lkml/2006/5/22/278
CPU for [1]:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(tm) XP 2000+
stepping        : 0
cpu MHz         : 1666.774
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up
bogomips        : 3333.54
clflush size    : 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts

<Prev in Thread] Current Thread [Next in Thread>