On Thu, Apr 08, 2010 at 04:12:41PM -0400, Bill Davidsen wrote:
Andreas Mohr wrote:
Clearly there's a very, very important limiter somewhere in bio layerYou are using a USB 1.1 connection, about the same speed as a floppy. If
missing or broken, a 300M dd /dev/zero should never manage to put
such an onerous penalty on a system, IMHO.
Ahahahaaa. A rather distant approximation given a speed of 20kB/s vs. 987kB/s ;)
(but I get the point you're making here)
I'm not at all convinced that USB2.0 would fare any better here, though:
after all we are buffering the file that is written to the device
- after the fact!
(plus there are many existing complaints of people that copying of large files
manages to break entire machines, and I doubt many of those were using
USB1.1)
https://bugzilla.kernel.org/show_bug.cgi?id=13347
https://bugzilla.kernel.org/show_bug.cgi?id=7372
And many other reports.
you have not tuned your system to prevent all of the memory from being used to cache writes, it will be used that way. I don't have my notes handy, but I believe you need to tune the "dirty" parameters of /proc/sys/vm so that it makes better use of memory.
Hmmmm. I don't believe that there should be much in need of being
tuned, especially in light of default settings being so problematic.
Of course things here are similar to the shell ulimit philosophy,
but IMHO default behaviour should be reasonable.
Of course putting a fast device like SSD on a super slow connection makes no sense other than as a test of system behavior on misconfigured machines.
"because I can" (tm) :)
And because I like to break systems that happen to work moderately wonderfully
for the mainstream(?)(?!?) case of quad cores with 16GB of RAM ;)
[well in fact I don't, but of course that just happens to happen...]