2015-08-18 13:06 GMT+02:00 J. Hannken-Illjes <hann...@eis.cs.tu-bs.de>:
> 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 ... > > Does anybody have an idea on how to prove this? I don´t know in what shape DTrace is (it´s not enabled in amd64/arm yet, is it?), but the function boundary tracer might be of advantage here. A comparison to the other BSDs would be interesting, too (if someone has that at hand). > -- > J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany) > >
