I have been following this post for some time.
I have installed Debian Lenny and started using that as a primary system
and the Ubuntu system I have I tinker with.
Call me a rebel or such.. but I have noticed differences on how the
systems' (Ubuntu and Debian) handle file transfers.
I am not
this problem lasts for me since 8.04 when i just started using linux. i
have it by now and none of the proposed solutions helped
--
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,
2.6.31-16-generic #53-Ubuntu x86_64 Did not fix anything for me ;o(
I did some further testing and the problem appears to be related to per
file transfer and also to USB stick you use.
I did test with
1. Kingston micro SD HC 8GB memory card using with mini usb card reader.
trasfered about
I also did some Tests...
Copying file to a MP3 Player ( FS MSDOS ) i had similar Problems as described
above.
Copying Files to a external USB Hardisc ( FS EXT3 ) I don't see such problems.
Maybe the coses come from different File Systems ?
Regards Sbec
--
file transfers on USB disk are very
I have been following this bug report for a long time now and here is
some advice to the people that have only recently begun to post here.
This bug has hundreds of postings and no reasonable person could
possible read all of them in order to start fixing something.
Through time it has become
sbec67: The difference isn't the file systems, it's that hard drives are
treated differently to USB sticks. As I wrote before... copying to
external drives gives me 15MB/s sustained.
--
file transfers on USB disk are very slow
https://bugs.launchpad.net/bugs/197762
You received this bug
I can concur with Digital5700. My 1TB external drive has no performance
issues, but my 8GB flash drive has trouble getting a 700MB file onto it in
a reasonable amount of time.
--
file transfers on USB disk are very slow
https://bugs.launchpad.net/bugs/197762
You received this bug notification
After playing around with the US mount options in my jaunty 64, I still
see this issue.
In my case, I think this is the result of using ubuntu on an NTFS USB drive: If
I copy and delete large files (4-8GB) in Jaunty, the USB drive gets fragmented
(expectedly so). If I plug this device to my
I have done some quick testing. I formatted my Kingston DataTraveler G2
16GB drive as a FAT32, FAT32 (lba), EXT2, EXT3 disk one at a time and
tried copying over a file little over 1GB in size. I monitored the
actual disk operations with dstat.
What I have found is that the first 100 - 200MB for
One more thing...
I don't know if this is related, but whenever I try to Safely remove
the disk I always got this error:
Unable to stop drive
Error detaching: helper exited with exit code 1: sense buffer empty
Error SYNCHRONIZE CACHE for /dev/sdb: Success
start stop unit: transport:
Botond,
Again, I would ask that you take a look at the procedures found here:
https://help.ubuntu.com/community/DiskPerformance
... and then open another bug, complete with details of kernel version,
dstat -D dev when doing a dd if=/dev/zero of=dev bs=32k, and then
the output of dmesg | grep
i have the same problem here
read this: http://ubuntuforums.org/showthread.php?t=1306333
people are getting angry...
i think this Problem should be fixed with a Bug Fix and not within next release
Kind regards
Sbec
--
file transfers on USB disk are very slow
Latest kernel update (2.6.31-16-generic #53-Ubuntu x86_64) fixed my
problem.
--
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
2.6.31-16-generic #53-Ubuntu x86_64 fixed my problem too.
--
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
Same problem here copying 100MB from the disk to an USB key using
Nautilus (drag n drop from Nautilus to Nautilus).
During the copy, the gnome desktop is mostly frozen, the copy progress bar only
appears after after *minutes* and once appeared, is hardly refreshed at all
before the end of the
I see this bug is very old but still here and painful for many people, is there
anything we can do? provide some more info? is there anyone looking at it? Was
this problem understood already?
I think priority should be risen, what should we do when we need to take larger
file on USB? what is
I think the bug along with the reports needs to be split into:
kernel issues - when even reading from/writing to the block device with
hdparm/dd is unreasonably slow
block filesystem issues - testing the above works,but copying files to/from
the filesystem (preferably from something not impacted
I am using Karmicl, kernel 2.6.31 -15 -generic on my laptop. The time
that takes to transfer files to my USB drives takes almost 20 times more
than it used to take in Jaunty. Sometimes after waiting for a long time
of transfering it will simply give a error message or the file will
simply will not
Anything new on this bug?
i am having this issue with my usb :
Bus 001 Device 007: ID 058f:6387 Alcor Micro Corp. Transcend JetFlash Flash
Drive
copying 170mg file after 70% tends to slow down.using krusador and also natilus.
i am willing to provide any other info if required.
using ubuntu 9.10
I do not see this option in karmic
Carlos M wrote:
Sergey
Once the USB thumbdrive is mounted, you can right-click on its desktop icon
and select Properties. From there you will see the Volume tab and specify
the mount options
Carlos M
--
file transfers on USB disk are very slow
I do not see this option in karmic, either
--
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
Carlos, where did you find USB-Properties-Volume-Mount menu?
--
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
Sergey
Once the USB thumbdrive is mounted, you can right-click on its desktop icon and
select Properties. From there you will see the Volume tab and specify the
mount options
Carlos M
--
file transfers on USB disk are very slow
https://bugs.launchpad.net/bugs/197762
You received this bug
From what I googled, it appears the 'noatime' option implies
'nodiratime' as well. I was able to specify this option in the
USB-Properties-Volume-Mount options. It seemed to work when I
transfered two 4.2GB movies but I'll keep an eye on it -- I'm not sure
it's fixed in my case. Also, this
@ Luis (#198): can you please post/link to the changes made to fstab? I
have no lines in fstab for USB drives, as DeviceKit is supposed to take
care of that.
@everyone having problems and still following: how many of you tried to
bypass the filesystem by using dd or hdparm -t?
Running Karmic
** Attachment added: Data sheet.ods
http://launchpadlibrarian.net/35911171/Data%20sheet.ods
--
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.
--
Thanks Ulrich,
I have started to log items and placed the data in a ODS file posted
above. Message and attachment did not go through together.
I started with data being written to a .txt file to home directory. . .
changed to the /dev/shm directory so data written to the file would not
conflict
I had this problem, and after reading all this comments, i decided to
give it a try to the reconfiguration of fstab
I went from 4 MB to a steady 30MB (this is the REAL max throughput of a
USB device in USB 2.0)
It worked perfectly. Also, setting my SATA Ports to use 32 bit and it
made it a
Dear Shawn,
dstat does essentially that.
Default is one line of output every second, which means the output
equals the MiB/sec throughput of your device.
Try dstat -D sda,sdb. You can also adjust the delay; see the manual page.
--
file transfers on USB disk are very slow
At this moment, the only way to survive at this bug is open an ftp or sftp
connection in local host and copy files with filezilla or similar client
O_O.
It's an absurd solution, I know, but the only one that not freeze my
work.
by BAIS
2009/11/8 Dexter pogany.tamas+...@gmail.com
2 BAIS:
this doesn't help for my situation also. when copying by filezilla first 50mb
are copied quite fast, but after that great slowdown as if it was copied from
hdd.
--
file transfers on USB disk are very slow
https://bugs.launchpad.net/bugs/197762
You received this bug notification because
I will agree the FTP does not work for me either.
the best thing for myself was to do a reboot. transfers are good for the
first hour or two... then get mediocre and after a day possibly two...
abysmal.
rom85 wrote:
2 BAIS:
this doesn't help for my situation also. when copying by filezilla
I have the same problem, but rebooting doesnt help me.
--
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
Strange I used this method for gigas and gigas and I continued to work well,
I have kubuntu 9.04 daily updated.
I'm using server kernel, I don't know why :) Probably for some application
I've installed for testing.
I have a dream... this software on linux --
www.killprog.com Killcopy ! best file
I asked this some where but maybe not here...
I can't program, but is it possible to gather data via a script that
would put data into a sort of quasi time line format with certain data
appended to it..
i.e
start copy.
time bytes written rate
.
time bytes written rate
.
.
Bug confirmed on Karmic Koala
--
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
I have tried several PCs. They were based upon Intel chipsets such as G33/31,
i865, i915, i945 all with integrated video used. All of them had Celeron
proccessors on board, 512MM of RAM and SATA 80GB drives. Tested versions of
Ubuntu were 8.10, 9.04 and 9.10. None of them worked good, talking
those comments are not constructive could you restain from adding such
notes there?
--
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
Hello,
I am not a programmer and not that versed on how things in Linux work;
still quite Green.
Can a program be made to monitor a file transfer. i.e. track the
progress. there is something that is happening in the background.
The best file transfers I have is just after a reboot of the
** Tags added: karmic
--
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
LOL, same patch applied here, having something as basc as USB communications
breaking down essentially breaks the entire OS for most people, i really
wanted Ubuntu to be my last OS but this bug killed it
On Thu, Oct 29, 2009 at 10:53 PM, Ulrich Lukas
stellplatz-nr@datenparkplatz.de wrote:
I also suffer from this bug. The transfer speed seems to start high and then
falls to kb/s after a short while, see below.
This happens with nautilus, dd, and rsync, etc.
$ rsync -aP * /media/usbmedibig --stats
sending incremental file list
file1
367,481,854 100% 10.67MB/s0:00:32
Martin and Murz,
maybe you can get help if you open up an individual, detailed bug
report.
Given that this 184-message bug report is over one and a half year old,
I'm afraid adding comments here does not help.
This bugfix works, I've just tested it:
Confirm this problem in Kubuntu Karmic RC amd64 fresh install: transfering a
big file (more that 600 mb) to the USB disk is very slow and get about 100% of
CPU usage (on AMD Athlon(tm) 7550 Dual-Core Processor with 4gb of RAM) all the
copying time.
Can I help with some additional debug info?
trying to rsync a windows 7 install dvd
the issue seems different from a speed one, you should open a new bug
rather than commenting there...
--
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
I got the same slowness when trying dd to the same stick. It was fast
at first and gradually got slower (according to kill -USR1 dd) and ended
up at about 300k/s.
--
file transfers on USB disk are very slow
https://bugs.launchpad.net/bugs/197762
You received this bug notification because you
I got this in dmesg when trying to rsync a windows 7 install dvd to a 4G flash
drive:
[227761.643001] INFO: task pdflush:19635 blocked for more than 120 seconds.
[227761.643010] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables
this message.
[227761.643016] pdflush D
I can reproduce this every time, please tell me what kind of debug info
you need.
--
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
In Karmic transfering a file to the USB disk it is a slight bit faster
compared to Jaunty, but moving a big file it is still painfully slow.
--
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
There are 2 changes in recent Karmic kernels that should help:
2.6.31-10.35:
* [Config] Set default I/O scheduler to DEADLINE
CFQ seems to have some load related problems which are often exacerbated by
sreadahead.
- LP: #381300
2.6.31-11.38
* sched: Disable NEW_FAIR_SLEEPERS for now
** Changed in: linux (Ubuntu)
Importance: Undecided = Medium
** Changed in: linux (Ubuntu)
Status: Confirmed = Triaged
** Changed in: linux (Ubuntu)
Assignee: Ubuntu Kernel Team (ubuntu-kernel-team) = (unassigned)
--
file transfers on USB disk are very slow
Luckily, the extermely slow USB transfer rate gives me ample time to
enjoy the 173 comments in this bug report.
Whoooppeee!
--
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,
Same issue with Corsaire Voyager Mini 16G. Works reasonably fast under
WinVista
--
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
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
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
, 2009 4:43 PM
To: kuli...@afikim.org.il
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
On Wed, Jul 15, 2009 at 11:33:07AM -, kulight 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
(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
This is completely not flamebait, promise, I have been doing nothing but
bragging on the latest build of Ubuntu, but I loaded Windows 7 back on this
same exact machine, only difference was the OS, and suddenly I get transfer
speeds of 25Mb/s or higher consistently even on extremely large
Eric,
The problem is that your problem may be very different from other
peoples' problem. First of all, in your test, you are continually
dirtying the page cache with cp /dev/zero /mnt/bigfile.This brings
in filesystem effects, and VM effects, and so it's hard to tell what is
actually going
jamesnmandy,
For someone who 'does not have the time to file a proper bug report',
you seem to have plenty of time to write notes complaining about the
bug. Seriously --- if you aren't willing to help determine the problem
--- and you like GUI solutions --- maybe you should just go back to
On Wed, Jul 15, 2009 at 01:55:49AM -, Theodore Ts'o wrote:
Eric,
The problem is that your problem may be very different
I ran some tests and found out that my USB flash disk is significantly
slower when it is formatted as FAT32, compared to ext3.
I have created a new bug, which can be found here:
https://bugs.launchpad.net/ubuntu/+bug/392089
--
file transfers on USB disk are very slow
Who wants my Hardware?
Since I can't use my USB drive (I cancelled the last attempt to copy
6GiB after more than one hour and less than 10%):
Whoever wants to do further testing or bugfixing:
You get my 16-GiB USB pen drive for for free! I can send it to you
worldwide in a cushioned envelope.
ons, 10 06 2009 kl. 22:38 +, skrev jamesnmandy:
Hiding behind a proper bug request gets us nowhere.
And you posting useless information in this bug does?
It's not working like it is supposed to and that's painfully obvious.
And it should be painfully obvious by now that the issue cannot
[1] https://bugs.launchpad.net/ubuntu/+bug/334914/comments/30
[2] 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 member of Ubuntu
Desktop Bugs, which is a
man, 08 06 2009 kl. 20:14 +, 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
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 thoseyou know, former Windows
users, who do everything with a GUI and if there's not a double click or
Not sure if this has been mentioned or not, but I noticed today that
performance is much much better when copying directories to directories vs.
copying a file to a directory. For example, I had a directory on my
desktop, with three subdirectories, each with two files in them. When I
right-click
On Mon, Jun 8, 2009 at 9:54 PM, jamesnmandy jamesnma...@gmail.com
wrote:
There's no way all these people are seeing this behaviour because they all
have vastly different yet commonly crappy hardware. The same exact
hardware works great under the other OS. It's 100% a *nix issue and
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.
Sysstat shows it as
There's no way all these people are seeing this behaviour because they all
have vastly different yet commonly crappy hardware. The same exact
hardware works great under the other OS. It's 100% a *nix issue and it's
100% in the software. That's painfully obvious. I wish this would get
fixed
I can reproduce on my Ubuntu 9.04 64 bit so far.
--
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
MVDHR,
and why should we care? This bug has been open for a year and 50 people
have commented here, so news would be that the problem actually went
away. You give no information that helps further debug the issue, please
read https://help.ubuntu.com/community/DiskPerformance and diagnose your
Testing with a Kingston DataTraveler on 2.6.27-14-generic x86_64 Ubuntu
9.04.
copying from /dev/zero
robe...@roberto-desktop:~$ dd if=/dev/zero of=/media/KINGSTON16/test-file bs=512
1038321+0 registros entrando
1038321+0 registros saindo
531620352 byte (532 MB) copiados, 18,2775 s, 29,1 MB/s
A
** Attachment added: dmesg from blazing fast ipod
http://launchpadlibrarian.net/26989377/dmesgipod.txt
--
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
Night64:
No, you're using usb-storage device driver for both the pendrive and the
ipod.The messages that you quoted as coming from the ipod just means
that the usb-storage module had gotten unloaded, and when it was loaded
as a module, it prints those lines to the kernel log. The fact that
Night64,
flash devices are slow and the only reason the transfer appears to be
fast at the beginning is that data is written to OS memory and then
later to disk. Use dstat to monitor disk performance as explained on
https://help.ubuntu.com/community/DiskPerformance, And open new bug
reports
Thanks for the info, Ts'o. But your comment about libusual caught my eye. In
Ubuntu 9.04 this module still shows up, right?
[81601.434729] usbcore: registered new interface driver libusual
Linux: Because rebooting is for adding new hardware.
Sent from Brasilia, DF,
On Wed, May 20, 2009 at 08:48:34PM -, Night64 wrote:
Thanks for the info, Ts'o. But your comment about libusual caught my eye. In
Ubuntu 9.04 this module still shows up, right?
[81601.434729] usbcore: registered new interface driver libusual
Oops, sorry, that's what I get for not
I did have a long list of tests to attach here, but using dstat over the
last couple of hours it appears that one of my drives that is connected
via eSATA might be faulty. Until last week when I purchased a new 640GB
I was using it (WD 500GB ext4) as my desktop drive and prior to that as
my
System running Ubuntu Jaunty AMD64, vanilla 2.6.29.1. KDE4.2, two
terminal windows, no other graphical applications.
I created two test files of identical size with random data and copied to the
USB pendrive, once on a freshly rebooted system, and once after I first
experienced a slowdown while
** Attachment added: Output of dstat -D sda,sdb, showing expected performance
http://launchpadlibrarian.net/26929198/dstat-D.OK.850-MiB-random-data.txt
--
file transfers on USB disk are very slow
https://bugs.launchpad.net/bugs/197762
You received this bug notification because you are a
** Attachment added: Output of dstat -D sda,sdb, showing slowdown
http://launchpadlibrarian.net/26929209/dstat-D.slow.850-MiB-random-data.txt
--
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
Ulrich --- if you have time to try to do more tests, may I gently
suggest that you start a new Launchpad bug?Drop a pointer from in
this launchpad bug number to the new one, but let's do all of the
experimentation on a new launchpad bug. There are a couple of reasons
for this:
(1)
Hi, I am experiencing a similar problem on a fresh jaunty install when copying
files to an USB hdd. I do not even need to
transfer large files, transferring around a few mp3-s kills the transfer rate
in a few seconds.
Theodore-- I will try to get some time and start collecting the info you
So, I believe I am the one Theodore refered to as venting how the
useless Ubuntu bug reports are. While they really are, I also really
want to help.
So, following Theodore's suggestion I've started
https://help.ubuntu.com/community/DiskPerformance on the Ubuntu Wiki. It
is pretty basic right now,
No, it's not Ubuntu specific and Canonical didn't cause it.
Right now I'm copying between two SATA drives, connected to my PC via
eSATA. So far a lousy 600MB has been copied and I'm already down to
5MB/s and falling.
Here is what I know about the problem:
It affects ALL hardware.
It affects
For people who are seeing this --- try booting the kernel with the
mem= command line option and see if this makes a difference. For
example if you have 4 gigs of memory, try using mem=1G; if you have a
gig of memory, try using mem=512M. Does this change how big the file
needs to be before you
Something else to try; I would suggest using dstat with the -D option
(i.e, dstat -D sda,sdb) or iostat 1 (although I find dstat to be a bit
more user friendly) to measure I/O transfer rates. I would recommend
using dd if=/dev/zero of=/media/disk/test.img bs=32k to measure the
transfer rates,
Theodore, thanks for the info.
I don't have a lot of time this morning before work, but I was able to
run one test which illustrates the problem. In the attached dstat
output, I copied 3.4GB between two eSATA HDD. It started off fast (as
usual), but by the time the copy finished the dialog was
Forgot to mention, that dstat is for the destination drive only. I'm
also not seeing as much of a slowdown if I copy from the source to the
internal drive, then to the destination drive.
--
file transfers on USB disk are very slow
https://bugs.launchpad.net/bugs/197762
You received this bug
I wil have to disagree with about ram. busy trying to clone my root
partition with dd to a usb hard drive. booted with jaunty 32bit live cd
and started the process with dd if=/dev/sda3 of=/media/disk/image.img
conv=sync,noerror bs=64K. 1st 10GB flew by at 25-30MB/s then started
slowing down to
backup is now at 64GB and has slowed down to 500KB/s and I will have to
stop it.
Usb is now officially a completely useless backup tool on linux.
just stopped it, dd claims 65GB has been copied avg 1.5MB/s
like to mention that this has always been a very intermittent issue.
sometimes works fine
Hello,
this bug isn't ubuntu specific I think.
I can reproduce this problem with Debian 3.1/4.0/5.0 and linux 2.6.29 too.
Can you try it with Ubuntu 6.06 again? There doesn't affects me this problem...
--
file transfers on USB disk are very slow
https://bugs.launchpad.net/bugs/197762
You
Hi Lucas,
I noticed everything goes fine until the memory gets full, then starts
the swapping and the slowdown. It's like the memory is used as buffer,
when that runs out it uses the virtual memory on the HD. No problem with
small sizes that fit the memory but when you select 100 GB at once ...
I had the same problem, needed to backup 200+ GB to a USB HD due to a
hardware upgrade. Then I remembered the board had a strange bios reset
recently (hence the upgrade) so I checked and set the bios SATA
configuration back from IDE to AHCI (My mobo has 3 possible settings
IDE, RAID and AHCI). Now
Hi Kurt,
albeit the AHCI-mode enables the use of Native Command Queueing (NCQ)
for some mainboards, I somehow doubt that this has to do with the USB
issue. Especially because of the swapping you reported which IMO has
nothing to do with the USB speed issues reported before.
--
file transfers
Same problem here, I have Thinkpad T500, starting speed was about 15
MB/s and at the end only about 3 MB/s, size of transfered file is 3,2 GB
dist: jaunty 64 bit
--
file transfers on USB disk are very slow
https://bugs.launchpad.net/bugs/197762
You received this bug notification because you are
** Changed in: linux (Ubuntu)
Status: Incomplete = Confirmed
--
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
1 - 100 of 175 matches
Mail list logo
