Well, you can finde a previous discussion here:
http://mail-index.netbsd.org/tech-kern/2014/08/22/msg017539.html
The point was that creating many (even empty) files leads to a very high kernel CPU consumtion along with
almost no disk activity. What happens behind the scenes is still unknown to me. One should check whether
WAPBL makes a difference here (mount option "log" enables WAPBL journaling). It might be helpful to have
DTrace working in order to investigate this.
Cheers!
2015-07-09 12:33 GMT+02:00 Jean-Baka Domelevo Entfellner <domelevo%gmail.com@localhost>:
Hallo Stephan,
Thanks for the advice: yes, you were damn right! With the dd command
you gave as example, on top of the untarring, we get very different
values:
tty ld0 CPU
tin tout KB/t t/s MB/s us ni sy in id
0 19 7.825 17 0.128 0 0 1 3 95
0 131 64.00 70 4.394 0 0 34 2 64
0 44 64.00 85 5.322 0 0 31 11 58
0 44 64.00 73 4.579 0 0 33 8 59
0 44 64.00 72 4.517 3 0 30 6 61
0 44 63.19 58 3.605 0 0 3 6 91
0 44 14.77 64 0.928 0 0 21 1 78
0 44 64.00 60 3.775 0 0 36 8 56
0 44 64.00 69 4.332 1 0 36 2 61
0 44 64.00 56 3.527 0 0 25 3 72
0 44 64.00 55 3.465 1 0 24 3 72
0 44 64.00 56 3.527 1 0 25 2 72
0 44 64.00 57 3.589 1 0 20 6 73
0 44 64.00 68 4.270 0 0 29 6 65
0 44 64.00 73 4.579 3 0 29 6 62
0 44 63.30 68 4.223 0 0 4 7 89
0 44 40.49 88 3.485 1 0 44 4 51
^C
rpi$ fg
dd if=/dev/zero of=myfile bs=4k
^C20720+0 records in
20719+0 records out
84865024 bytes transferred in 20.350 secs (4170271 bytes/sec)
So this means approximately 4MB/s, and that's indeed the nominal speed
of my microSD if it's indeed a class 4 card. Will check that once I
can switch the RPi off. Thanks!
So ffs is slow with creating files... Why is it still the standard in
NetBSD? Is the format of my partition (displayed with fstype=4.2BSD in
"disklabel /dev/ld0") also called "UFS1"? Would the format called
"UFS2" be faster regarding file creation?
And just another off-topic question sparked by this one: is there
really an added value in specifying "bs=4k"? According to the manpage,
the default is one sector, 512 bytes. When I use it (dd if=/dev/zero
of=myfile), I get 3048728 bytes/sec instead of 4170271 bytes/sec with
"bs=4k". Is that discrepancy explainable and reproducible? Thanks for
sharing your light! :)
JB
On Thu, Jul 9, 2015 at 11:39 AM, Stephan <stephanwib%googlemail.com@localhost> wrote:
> Can you please check the speed of sequential write (e.g. dd if=/dev/zero
> of=myfile bs=4k)? FFS has always been slow with allocating new files, which
> certainly contributes to the issue you?re seeing.
>
> 2015-07-09 11:28 GMT+02:00 Jean-Baka Domelevo Entfellner
> <domelevo%gmail.com@localhost>:
>>
>> Hi there,
>>
>> I'm currently untarring a pkgsrc.tar.gz (48MB) to /usr. The
>> commandline I used is:
>> # nohup tar xfz pkgsrc.tar.gz -C /usr &
>>
>> so nothing is written to the stdout, it justs gunzips and untars. And
>> I have the feeling it's extremely slow. I'm running:
>> NetBSD rpi 7.0_RC1 NetBSD 7.0_RC1 (RPI.201507072130Z) evbarm
>> and it's on a RaspberryPi model B+
>>
>> The microSD card is an ADATA (32GB), I don't think it's class 10,
>> maybe class 4 (can't remove it from its slot now while the RPi is
>> running). The boot messages concerning it are:
>> ld0 at sdmmc0: <0x03:0x5344:SS32G:0x80:0x2554f92d:0x0e4>
>> ld0: 30436 MB, 7729 cyl, 128 head, 63 sec, 512 bytes/sect x 62333952
>> sectors
>> ld0: 4-bit width, bus clock 50.000 MHz
>>
>> So, while the untarring command is running, I check the speed with iostat:
>>
>> tty ld0 CPU
>> tin tout KB/t t/s MB/s us ni sy in id
>> 0 20 7.767 15 0.113 0 0 1 3 95
>> 0 131 8.194 31 0.246 0 0 3 3 94
>> 0 44 7.871 31 0.236 0 0 1 3 96
>> 0 44 7.793 29 0.219 1 0 1 2 96
>> 0 44 8.133 30 0.236 0 0 2 2 96
>> 0 44 7.871 31 0.236 0 0 1 1 98
>> 0 44 7.793 29 0.219 0 0 1 4 95
>> 0 44 7.939 33 0.253 0 0 2 1 97
>> 0 44 7.931 29 0.222 0 0 0 2 98
>> 0 44 7.571 28 0.205 0 0 6 4 90
>> 0 44 7.793 29 0.219 0 0 3 2 95
>> 0 44 8.294 34 0.273 0 0 3 5 92
>> 0 44 8.000 28 0.217 0 0 3 0 97
>> 0 44 8.067 30 0.234 0 0 0 3 97
>>
>> It's on average between 0.20 and 0.25 MB/s, don't you think it's
>> unreasonably slow? Do you have any piece of advice for me?
>>
>> Thanks,
>> JB
>
>