Ext4 vs XFS — различия между версиями

Материал из YourcmcWiki
Перейти к: навигация, поиск
м (filebench fileserver, dirty_ratio=1%)
м
Строка 1: Строка 1:
 +
= Features =
 +
 +
 +
 +
= Benchmarks =
 +
 
== Copy kernel source (from SSD with warm cache) ==
 
== Copy kernel source (from SSD with warm cache) ==
  
HDD: WD Scorpio Black 2.5" 750GB 7200rpm
+
* HDD: WD Scorpio Black 2.5" 750GB 7200rpm
 +
* Kernel: 3.12.3
  
 +
Results:
 
* xfs 1 thread: 12.348s
 
* xfs 1 thread: 12.348s
 
* xfs 4 threads: 65.883s
 
* xfs 4 threads: 65.883s
Строка 11: Строка 19:
  
 
* HDD: WD Scorpio Black 2.5" 750GB 7200rpm
 
* HDD: WD Scorpio Black 2.5" 750GB 7200rpm
 +
* Kernel: 3.12.3
 
* fs_mark is a write-only test and it does fsync(), so there should be no skew caused by page cache
 
* fs_mark is a write-only test and it does fsync(), so there should be no skew caused by page cache
  
Строка 47: Строка 56:
  
 
* HDD: WD Scorpio Black 2.5" 750GB 7200rpm
 
* HDD: WD Scorpio Black 2.5" 750GB 7200rpm
 +
* Kernel: 3.12.3
 
* sysbench was ran with O_DIRECT, so the page cache should also have no impact.
 
* sysbench was ran with O_DIRECT, so the page cache should also have no impact.
 
* It’s not a filesystem benchmark at all! It tests disk performance because it holds ALL prepared files open during the test. It only shows us that XFS isn’t slowing down the direct access to the underlying device (which is also good, of course)…
 
* It’s not a filesystem benchmark at all! It tests disk performance because it holds ALL prepared files open during the test. It only shows us that XFS isn’t slowing down the direct access to the underlying device (which is also good, of course)…
Строка 85: Строка 95:
 
== sysbench random read/write 16K in 16K files ==
 
== sysbench random read/write 16K in 16K files ==
  
HDD: WD Scorpio Black 2.5" 750GB 7200rpm
+
* HDD: WD Scorpio Black 2.5" 750GB 7200rpm
 +
* Kernel: 3.12.3
  
 
<plot>
 
<plot>
Строка 122: Строка 133:
  
 
* HDD: WD VelociRaptor WD6000HLHX, 10000rpm
 
* HDD: WD VelociRaptor WD6000HLHX, 10000rpm
 +
* Kernel: 3.10.11 (Debian 3.10-3-amd64)
 
* fileserver test is read whole file + append + write whole file test ran on 10000 files in X threads
 
* fileserver test is read whole file + append + write whole file test ran on 10000 files in X threads
 
* filebench fails to run fileserver test with O_DIRECT, so I tried to "disable" page cache using dirty_ratio=1% and ran tests like this:
 
* filebench fails to run fileserver test with O_DIRECT, so I tried to "disable" page cache using dirty_ratio=1% and ran tests like this:
Строка 216: Строка 228:
  
 
* HDD: WD VelociRaptor WD6000HLHX, 10000rpm
 
* HDD: WD VelociRaptor WD6000HLHX, 10000rpm
 +
* Kernel: 3.10.11 (Debian 3.10-3-amd64)
 
* Same test but ran with default 20% dirty_ratio setting. It's clearly seen that the system was using page cache extensively - ext4 was permanently gaining an unreal result in the single-thread test...
 
* Same test but ran with default 20% dirty_ratio setting. It's clearly seen that the system was using page cache extensively - ext4 was permanently gaining an unreal result in the single-thread test...
  

Версия 20:33, 19 декабря 2013

Features

Benchmarks

Copy kernel source (from SSD with warm cache)

  • HDD: WD Scorpio Black 2.5" 750GB 7200rpm
  • Kernel: 3.12.3

Results:

  • xfs 1 thread: 12.348s
  • xfs 4 threads: 65.883s
  • ext4 1 thread: 7.662s
  • ext4 4 threads: 33.876s

FS-Mark 3.3, creating 1M files

  • HDD: WD Scorpio Black 2.5" 750GB 7200rpm
  • Kernel: 3.12.3
  • fs_mark is a write-only test and it does fsync(), so there should be no skew caused by page cache

sysbench random read/write 16K in 8M files

  • HDD: WD Scorpio Black 2.5" 750GB 7200rpm
  • Kernel: 3.12.3
  • sysbench was ran with O_DIRECT, so the page cache should also have no impact.
  • It’s not a filesystem benchmark at all! It tests disk performance because it holds ALL prepared files open during the test. It only shows us that XFS isn’t slowing down the direct access to the underlying device (which is also good, of course)…
  • Probably because of the above note, the filesystems don’t differ, and the results are totally same for 1x 1GB file and 128x 8MB files… and very similar for 3072x 16KB files (next test below).

sysbench random read/write 16K in 16K files

  • HDD: WD Scorpio Black 2.5" 750GB 7200rpm
  • Kernel: 3.12.3

filebench fileserver, dirty_ratio=1%

  • HDD: WD VelociRaptor WD6000HLHX, 10000rpm
  • Kernel: 3.10.11 (Debian 3.10-3-amd64)
  • fileserver test is read whole file + append + write whole file test ran on 10000 files in X threads
  • filebench fails to run fileserver test with O_DIRECT, so I tried to "disable" page cache using dirty_ratio=1% and ran tests like this:
echo 1 > /proc/sys/vm/dirty_ratio
echo 0 > /proc/sys/vm/dirty_bytes
echo 0 > /proc/sys/kernel/randomize_va_space
for i in 1 2 4 8 16 32 50 64; do
    echo
    echo "== $i threads =="
    echo
    echo 1 > /proc/sys/vm/drop_caches
    sync
    filebench <<EOF
load fileserver
set \$dir=/media/sdd
set \$nthreads=$i
run 30
EOF
done
echo 20 > /proc/sys/vm/dirty_ratio

filebench fileserver, dirty_ratio=20%

  • HDD: WD VelociRaptor WD6000HLHX, 10000rpm
  • Kernel: 3.10.11 (Debian 3.10-3-amd64)
  • Same test but ran with default 20% dirty_ratio setting. It's clearly seen that the system was using page cache extensively - ext4 was permanently gaining an unreal result in the single-thread test...