Hiding behind a "proper bug request" gets us nowhere.  Additionally, I do
not have the time to do the research to figure out how to even begin to
"file a proper bug report".  I'm one of those....you know, former Windows
users, who do everything with a GUI and if there's not a double click or
next->next->finish wizard to do it, then it's not going to happen with me
and my machine.  I am what you would call the average user, average joe, who
just wants it to work like it's supposed to.  It's not working like it is
supposed to and that's painfully obvious.  I can tell you my same exact
hardware works multitudes better in terms of USB performance running the
other OS.  Not sure what a bug report has to do with that, it's a fact.  I
suppose you want average joe to show you how the software is messed up.  I'm
game for that as long as you make error logging and reporting an automated
thing.  Then you would not have to rely on people like me who obviously
don't know as much as yourself to find and implement bug fixes.

Thanks for your support.



2009/6/9 Simon Holm Thøgersen <email address hidden>

> man, 08 06 2009 kl. 20:14 +0000, skrev epv:
> > This isn't normal behavior. Obviously it behaves fine while all writes
> > are going to buffer cache, but once it tries to write it out to the
> > device, wait times on the partition shoot up to 30sec or more, and all
> > processes trying to touch the usb disk block practically forever.
>
> If other processes get completely starved due to the writeout then there
> is probably something in the VM, file system or I/O scheduler that needs
> to be fixed. You would have to make a convincing argument, though, like
> providing a very simple usecase. It should literally be something as
> simple as the following
>
> (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).
>
> > Sysstat shows it as 100% busy continuously.
>
> 'It' being the underlying device? That is what you would expect.
>
> > 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?
>
> > 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).
>
> [1] https://help.ubuntu.com/community/DiskPerformance
>
> --
> file transfers on USB disk are very slow
> https://bugs.launchpad.net/bugs/197762
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in gvfs: Invalid
> Status in “gvfs” source package in Ubuntu: Invalid
> Status in “linux” source package in Ubuntu: Confirmed
>
> Bug description:
> When transferring large files (800meg) or even medium-size files (200meg),
> the transfer rate decreases constantly. It starts at around 4meg/sec and
> goes down to even less than 800kb/s. When I cancel the download and start it
> over again, the transfer rate comes back up to 4meg/sec.
> I am using Nautilus on Ubuntu 8.04 (hardy heron)
>