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 protected]> 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 protected] [mailto:[email protected]] On Behalf Of > Theodore Ts'o > Sent: Wednesday, July 15, 2009 4:43 PM > To: [email protected] > 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) > -- 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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
