On 18 Aug 2015, at 12:44, Stephan <stephan...@googlemail.com> wrote: > 2015-08-17 21:30 GMT+02:00 Michael van Elst <mlel...@serpens.de>: > stephan...@googlemail.com (Stephan) writes: > > >I have just rebooted with WAPBL enabled. Some quick notes: > > >-Sequential write speed is a little lower, around 5,4 MB/s. > > > WAPBL is rather slow on SD cards because SD cards are very slow > when writing small chunks. So even when WAPBL excels, like unpacking > lots of files or removing a directory tree, it is slow because the > sequential journal is written in small blocks.
The journal is written in chunks of MAXPHYS (64k) bytes. > That might be all right. However, creating many files becomes worse the more > files are being created. That is on all kinds of devices I´ve seen. > > This is from an amd64 server box with an aac raid controller. > > /root/test/files> time seq 1 10000|xargs touch > 3.10s real 0.01s user 3.07s system > /root/test/files> rm * > /root/test/files> time seq 1 20000|xargs touch > 9.88s real 0.01s user 8.51s system > /root/test/files> rm * > /root/test/files> time seq 1 30000|xargs touch > 23.45s real 0.04s user 20.41s system > /root/test/files> time seq 1 40000|xargs touch > 43.35s real 0.05s user 38.32s system > > That is clearly not linear. I'm quite sure this is the memcmp in ufs_lookup.c:390. For every file we have to compare its name to all names in the directory so far leading to 0.5*n*(n-1) calls to memcmp. And our memcmp is sloooow ... -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
