> 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 layer
>>> missing or broken, a 300M dd /dev/zero should never manage to put
>>> such an onerous penalty on a system, IMHO.
>>>
>>>
>> You are using a USB 1.1 connection, about the same speed as a floppy. If
>>
>
> 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...]
>
