When I run bonnie on my magneto-optical drive linux seems
windos running on a vic-20. The system is completely unusable. For
example Netscape takes 1 minute to show a message storen in my
homedir! Everything that tries to write something to the disk
remains blocked in D state for 10s of second. I'm talking of
files stored on my HD, not on the MO drive, and the're on
different controllers.
I changed /proc/.../freepages to have 10MB of free mem, so I really
can't see a good reason to delay all disk accesses so much.
Then I tried this:
dd if=/dev/zero of=xxx bs=1024 count=10000 (10MB)
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 1 0 1400 72832 40260 18756 0 0 0 2827 27 436 4 20 76
0 1 0 1400 72832 40260 18756 0 0 0 320 11 357 0 2 98
0 1 0 1400 72832 40260 18756 0 0 0 320 9 345 0 2 98
0 1 0 1400 72832 40260 18756 0 0 0 288 9 344 1 1 98
0 1 0 1400 72832 40260 18756 0 0 0 320 10 356 1 1 98
0 1 0 1400 72828 40260 18756 0 0 0 288 90 378 0 2 98
0 1 1 1400 72828 40260 18756 0 0 0 289 144 393 1 1 98
0 1 1 1400 72828 40260 18756 0 0 0 320 64 377 2 1 97
0 1 0 1400 72828 40260 18756 0 0 0 49 113 394 0 3 97
0 1 0 1400 72828 40260 18756 0 0 0 0 46 376 0 3 97
It looks OK.
but:
dd if=/dev/zero of=xxx bs=1024 count=100000 (100MB)
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
1 0 0 1400 72928 40260 18756 0 0 68 67 70 450 3 2 95
0 1 1 1400 72796 40260 18756 0 0 0 2891 38 407 4 38 58
0 1 1 1400 72796 40260 18756 0 0 0 320 10 350 0 4 96
1 0 0 1400 72796 40260 18756 0 0 0 289 10 349 0 3 97
0 1 1 1400 72796 40260 18756 0 0 0 319 9 346 1 3 96
0 1 1 1400 72796 40260 18756 0 0 0 288 9 359 0 4 96
0 1 1 1400 72796 40260 18756 0 0 0 320 10 352 2 1 97
0 1 2 1400 72796 40260 18756 0 0 0 103 9 352 1 3 96
0 1 2 1400 72796 40260 18756 0 0 0 10 10 361 0 2 98
0 1 2 1400 72796 40260 18756 0 0 0 9 9 351 0 2 98
0 1 2 1400 72796 40260 18756 0 0 0 9 9 363 0 2 98
0 1 2 1400 72796 40260 18756 0 0 0 10 10 361 1 1 98
0 1 2 1400 72792 40260 18756 0 0 0 9 369 518 2 2 96
0 1 2 1400 72792 40260 18756 0 0 0 10 73 386 3 1 96
0 1 2 1400 72792 40260 18756 0 0 0 9 9 359 1 1 98
0 1 2 1400 72792 40260 18756 0 0 0 9 9 354 1 1 98
0 1 2 1400 72792 40260 18756 0 0 0 137 13 370 1 2 97
0 1 2 1400 72792 40260 18756 0 0 0 672 39 437 0 2 98
0 1 2 1400 72792 40260 18756 0 0 0 20 20 388 2 1 97
0 1 2 1400 72792 40260 18756 0 0 0 20 353 507 1 1 98
0 1 2 1400 72784 40260 18756 0 0 0 21 300 428 1 2 97
...
Blocks-out rate drops to a ridiculous speed after a few second, with a small
burst every 10-15 sec. The drive can write at about 600KB/s, so "bo" should
be ~300 (2K blocks) all the time. Why ?
And why does it affects output on other devices ?
Uuhh, I've just noted that sync and kupdate are blocked in D state...
wonderful.
Ah, it's just returned. They took 2m27s doing absolutely nothing :-((
The strange thing is that as soon as I can break dd, it restart writing at
the right speed. Perhaps there is something wrong in the new elevator code ?
I have 192MB or ram. I also tried booting with 64MB (my old PMac have 64MB
and it doesn't show this problem with the same kernel - only the SCSI
driver differs) and it behaves about the same, but at the beginning of
the test the drive writes at the right speed for ~30 sec instead of ~8.
Is it possible this problem is caused by the SCSI driver ? I don't have
problems with my HD attached to another identical Adaptec 2930U.
[2.2.16, ppc750/350MHz]
Bye.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:18 EST