Well, my linux support fix my problem, even when I can't explain what is the
problem. But I pay for it!
Canonical have a nice and not very pricey support service, maybe you could
hire them.
----------------------------
Linux: Because rebooting is for adding new hardware.


On Wed, Jul 15, 2009 at 8:33 AM, kulight <email address hidden> wrote:

> I've just remembered why the user base of Linux is so small
>
> I do actually expect my mechanic to find and fix what's wrong with my car
> when I just tell him it won't start
> And I don’t care if it's the engine the battery or the radiator
> You have to understand that most users have no idea where the problem is
> coming from or if its two separate ones
> They are just using the system and see the problems
>
> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of
> Theodore Ts'o
> Sent: Wednesday, July 15, 2009 4:43 PM
> To: <email address hidden>
> Subject: [Bug 197762] Re: file transfers on USB disk are very slow
>
> On Tue, Jul 14, 2009 at 08:45:56PM -0700, Ron Brogden wrote:
> > Theodore, if I may ask you - are you just another random Linux user
> > here or are you actually officially associated with Ubuntu in a
> > support role?  I see that you are associated with IBM, have written
> > some file system utilities and appear to be connected with kernel
> > development but am unsure your role here with respects to this bug.
>
> I'm a linux kernel developer, and yes, I'm the maintaining of the ext4
> filesystem and e2fsprogs.  I started paying attention to this problem
> because someone sent a note to the LKML (Linux Kernel Mailiung List)
> complaining that kernel developers don't pay attention to Ubuntu bugs.
>
> Keep in mind most Ubuntu users get Ubuntu for free, and pay no support
> fees; so it's not surprising that you will see very few Ubuntu support
> personnel paying attention to bugs like this one.  So at some level, the
> Ubuntu user community and Canonical has a choice to make.  If they
> are willing to let users just whine and whine and whine and _not_ help us
> by running experiments and opening separate bugs for each problem, and give
> full information (and we will provide them with explicit instructions on how
> to run those experiments), fine.  We can just go
> back to ignoring Ubuntu launchpad as being totally, completely, worthless
> for actually fixing bugs.  It can just be a place toxic sewer pit for users
> to whine, and if Canonical wants to pay someone to
> try to extract useful information (lots of luck; theres very little here)
> after the fact, they can go right ahead.  We'll just file Ubuntu into the
> "there's no intelligent life here" category, and ignore pleas for help on
> LKML when people ask developers to pay attention to Launchpad bugs.
>
> Alternatively, if the goal is to have one part of the community helping
> another, then the users have to be helpful.  That means doing research
> before filing bugs, and filing separate bugs for separate issues.
> Launchpad fails miserably when there are more than 80 comments; it's
> slow and painful to use.  So I am trying to see if we can salvage the
> Launchpad culture so it can be useful, but ultimately, maybe it's a
> losing battle, and we should give up.
>
> > Obviously most folks have no idea why their USB transfers are slow
> > but they know something is up.  It should be no surprise that they
> > post unclear bug reports since there is no real way for them to tell
> > whether their file manager, the kernel or some other bit of software
> > is the cause.  All they know is something is wrong and for those
> > that dual boot, it does not happen with Windows (not my situation
> > but it is far from uncommon).  Of course this is frustrating for the
> > bug fixer but then the response should be a request for hardware
> > that displays the problem at the very least (which I believe has
> > been offered here).
>
> The problem is that we need to separate out the reports.  When something
> is as vague as "disk transfers are slow", there's a extremely high
> probability that there may be multiple things going on. Some people
> might be having genuine hardware problems; others might be having
> filesystem issues.  Eric's (epv's) problem *might* be the classic
> ext3/fsync stalled write problem --- I can't tell, because _he_ hasn't
> filed a separate bug report and given information about his problem.
>
> Do you really expect a car mechanic to fix all problem descriptions of
> the form "my car is hard to start" simultaneously?  They all have the
> same symptoms, so *obviously* they must have same root cause.  NOT.
>
> > Since you are apparently a file system expert, how about writing a
> > quick utility that gives out the details you think would be
> > pertinent for assessing file transfer speeds over USB?  This could
> > then be used as a benchmark and hopefully show once and for all
> > where the bottleneck is occuring.  Presumably hacking the cp source
> > (or dd or whatever) to add in some timing information is not a huge
> > undertaking.
>
> The 'dd' program already provides this information.  For example, like
> this:
>
>        sudo dd if=/dev/sdXX of=/dev/null bs=32k count=32k
>
> But we have people whining on this bug about how they are GUI persons
> only, and don't have time to do any research on the bug.  If all they
> are doing is whining, then maybe they should really go to Windows or
> MacOS.  Or they should get a paid support contract from some Linux
> distribution where someone can be paid to hold their hands.  There's No
> Such Thing As A Free Lunch, you know.
>
> > If you are not associated with Ubuntu support and are not actually
> offering
> > help then why are you polluting this bug report further than it already
> is?
>
> This bug report is already hopeless; the original bug report was against
> Ubuntu 8.04, over a year ago and two releases ago.  Which is why I
> suggest people who are really serious about solving the problem open
> fresh bug reports, with full and complete detail.  They should not
> assume that just because they have a similar problem, the hardware
> information submitted by someone else 12 months ago means they don't
> have to collect hardware information.
>
> --
> 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” package in Ubuntu: Invalid
> Status in “linux” 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)
>
> --
> 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” package in Ubuntu: Invalid
> Status in “linux” 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)
>