Comment 165 for bug 197762

> (cp bigfile /media/disk/ &) ; sleep 10 ; time echo foo > /media/disk/bar

> If the time is really in seconds as you seem to suggest it is
> interesting I'd say. On the other hand, if what you describe is due the
> low performance of the underlying device then it is expected behaviour
> (the low performance of the device might be due to a bug though).

# (cp /dev/zero /media/disk/bigfile &); sleep 10; time echo foo > /media/disk/bar

real 0m5.647s
user 0m0.000s
sys 0m0.004s

# time echo foo > /media/disk/foo2

real 0m3.534s
user 0m0.000s
sys 0m0.000s
# time echo foo > /media/disk/foo3

real 0m4.589s
user 0m0.000s
sys 0m0.000s
# time echo foo > /media/disk/foo3

real 0m16.913s
user 0m0.000s
sys 0m0.000s

Imagine that! I wasn't lying.

>> The reports of "Fast at
>> first, then slowing down" are of course because of the buffer cache
>> making it look like it's initially "fast" but access to the underlying
>> device is always very slow, whether you are writing to it with gvfs, cp,
>> dd, buffer, or whatever.
>
>Yes, and?

"and" so the arguments of "it's fast at first, then gets slow" from naive users are
spurious, which I'm sure you realized.

>> In addition, it's only writes that are slow, and they're vastly slower
>> than could be explained by a crappy USB device- in my case around 100 -
>> 200 kbytes/sec on a device that under a Hardy install writes at several
>> mbytes/sec.
>
> If Hardy was fine then you should open a new bug report with the proper
> details (once again, see [1] or Theodore's comments).

There has been a lot of unhelpful or misguided information posted to this bug,
but be careful not to discount the good with the bad. It's fairly clear you either
don't believe there's a problem or aren't interested in it, which is fine, but it
might be both more helpful and more civil to just say so, rather than being rude
to people who are trying to help with whatever means they have available.

eric