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 member of Ubuntu
Desktop Bugs, which is a bug assignee.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
