Re: Very slow transfers to/from micro SD card on a RPi B+

2015-08-18 13:06 GMT+02:00 J. Hannken-Illjes <hannken%eis.cs.tu-bs.de@localhost>:

On 18 Aug 2015, at 12:44, Stephan <stephanwib%googlemail.com@localhost> wrote:

> 2015-08-17 21:30 GMT+02:00 Michael van Elst <mlelstv%serpens.de@localhost>:
> stephanwib%googlemail.com@localhost (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 - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)