2013-12-20, 02:43
Results of restoring a tar backup of /storage from SSD on a Ubuntu 13.10 PC to a USB3.0 32GB memory stick:
f2fs is the clear winner here, almost double the write performance compared with ext4.
Testing on-Pi (1GHz/512MB) write performance with same 32GB drive:
Testing on-Pi read performance:
All on-Pi tests performed with xbmc.bin disabled, thus maximising CPU available for IO.
f2fs wins hands down on write performance, but is trumped by ext4 when reading.
allan87 raises a valid point, and when booting with f2fs /storage on USB, OpenELEC would experience a problem while booting about 50% of the time - the Pi didn't crash, but the boot sequence would never complete. The last boot messages to appear before slowing to a crawl:
(a few others messages appear subsequently, about 4 or 5 mintues later, probably as a result of timeouts)
so there is some instability to be expected when using f2fs, at least in my experience.
Personally, I'll be sticking with ext4 as I would rather not roll a dice each time I reboot the system but f2fs does show a great deal of promise.
Code:
Source: tar.gz, uncompressed data size: 2154MB (23685 files)
Restore to ext4:
#1: #2: #3:
real 5m54.159s 4m32.889s 5m30.590s
user 0m13.574s 0m13.317s 0m13.322s
sys 0m5.485s 0m5.535s 0m5.422s
Average: 5m 18 (6.7MB/s)
Restore to f2fs:
#1: #2: #3:
real 3m0.133s 3m3.485s 3m28.295s
user 0m13.255s 0m13.363s 0m13.485s
sys 0m4.779s 0m4.720s 0m4.493s
Average: 3m 10 (11.3MB/s)f2fs is the clear winner here, almost double the write performance compared with ext4.
Testing on-Pi (1GHz/512MB) write performance with same 32GB drive:
Code:
ext4:
# du -sk /storage/.xbmc/userdata/Thumbnails
1132112 /storage/.xbmc/userdata/Thumbnails
# find /storage/.xbmc/userdata/Thumbnails -type f | wc -l
20032
# time sh -c "cp -r /storage/.xbmc/userdata/Thumbnails /storage/downloads && sync"
#1: #2: #3:
real 5m 27.57s 5m 54.58s 5m 25.62s
user 0m 1.67s 0m 1.72s 0m 1.49s
sys 0m 37.13s 0m 37.70s 0m 37.78s
rm: rm: rm:
real 0m 4.49s 0m 4.52s 0m 4.53s
user 0m 0.31s 0m 0.32s 0m 0.36s
sys 0m 3.59s 0m 3.59s 0m 3.57s
Average: 5m 35 (3.3MB/s)
f2fs:
# du -sk /storage/.xbmc/userdata/Thumbnails
1212624 /storage/.xbmc/userdata/Thumbnails
# find /storage/.xbmc/userdata/Thumbnails -type f | wc -l
20032
# time sh -c "cp -r /storage/.xbmc/userdata/Thumbnails /storage/downloads && sync"
#1: #2: #3:
real 3m 27.98s 3m 34.52s 3m 35.85s
user 0m 1.70s 0m 1.51s 0m 1.49s
sys 0m 28.71s 0m 30.08s 0m 30.09s
rm: rm: rm:
real 0m 3.58s 0m 5.94s 0m 3.88ss
user 0m 0.31s 0m 0.37s 0m 0.33s
sys 0m 2.99s 0m 3.38s 0m 3.02s
Average: 3m 32 (5.7MB/s)Testing on-Pi read performance:
Code:
# time sh -c "tar cf - -C /storage/.xbmc/userdata/Thumbnails . >/dev/null"
ext4 (1.13GB data, 20032 files):
#1: #2: #3:
real 1m 8.80s 1m 9.11s 1m 9.10s
user 0m 1.95s 0m 1.96s 0m 1.95s
sys 0m 16.39s 0m 16.48s 0m 16.34s
Average: 1m 8 (16.6MB/s)
f2fs (1.21GB data, 20032 files):
#1: #2: #3:
real 1m 29.13s 1m 28.74s 1m 28.78s
user 0m 2.30s 0m 2.03s 0m 2.00s
sys 0m 17.63s 0m 17.50s 0m 17.75s
Average: 1m 28 (13.8MB/s)All on-Pi tests performed with xbmc.bin disabled, thus maximising CPU available for IO.
f2fs wins hands down on write performance, but is trumped by ext4 when reading.
allan87 raises a valid point, and when booting with f2fs /storage on USB, OpenELEC would experience a problem while booting about 50% of the time - the Pi didn't crash, but the boot sequence would never complete. The last boot messages to appear before slowing to a crawl:
Code:
[ OK ] Reached target System Initialization.
[ OK ] Listening on RPCbind Server Activation Socket.
[ OK ] Listening on D-Bus System Message Bus Socket.(a few others messages appear subsequently, about 4 or 5 mintues later, probably as a result of timeouts)
so there is some instability to be expected when using f2fs, at least in my experience.
Personally, I'll be sticking with ext4 as I would rather not roll a dice each time I reboot the system but f2fs does show a great deal of promise.
