I've got a SSD primary HD and a terabyte HD for storage. The terabyte hard drive is running sloooooow. It's taking 20+ minutes to move 1.5 gigs from the SSD to the terabyte HD. It's impossible to save anything big to the terabyte HD from GIMP. It'd take forever if it didn't crash GIMP hard. Need this fixed.
Announcement
Collapse
No announcement yet.
Second hard drive, very slow write.
Collapse
This topic is closed.
X
X
-
OK, so changing to ext4 and connecting via SATA isn't going to make any difference
What are the mount options for the second drive (from mount)? (Clutching at straws here...)
While a copy is running, does top report any processes maxing CPU? Does sudo iotop show anything unusual?
Have you fsck'd both drives?
My usual suspects for slow data transfer, apart from the speed of the interface itself and the drivers involved, are caching on write (but I don't think that applies to SATA) ... or errors.I'd rather be locked out than locked in.
- Top
- Bottom
Comment
-
Originally posted by SecretCode View PostWhat are the mount options for the second drive (from mount)? (Clutching at straws here...)
Originally posted by SecretCode View PostWhile a copy is running, does top report any processes maxing CPU? Does sudo iotop show anything unusual?
Googling around, kio_thumbnail is causing all kinds of trouble. I haven't figured out how to turn it off in Dolphin though.
The iotop command was "not found."
Originally posted by SecretCode View PostHave you fsck'd both drives?
- Top
- Bottom
Comment
-
You can install iotop from the repos
That kio_thumbnail utilisation sounds suspicious. Haven't seen such a process hogging CPU on my system.
Are you doing these copies from Dolphin? Does it make any difference if you use cp or rsync? And, thinking about it, does it make any difference if you boot into text mode, without starting the GUI?I'd rather be locked out than locked in.
- Top
- Bottom
Comment
-
I turned off all the previews in Konqueror and used it to copy a 230 meg file from SSD to TB HD. It took 5 minutes, during which I kept my eyeballs glued to the output from top. Kio_thumbnail never showed up, nothing used more than 2% cpu (plasma_desktop and Firefox) or a couple megs of RAM (Firefox).
The problem appears to be application independent. It's also slow saving from GIMP.
Let me try fsck next.
- Top
- Bottom
Comment
-
Result of fsck on the TB HD -
sudo fsck /dev/sdb1
fsck from util-linux 2.19.1
e2fsck 1.41.14 (22-Dec-2010)
manon: clean, 703/61054976 files, 6177685/244190000 blocks
At first I got an error message about trying to run fsck on a mounted drive. I unmounted the TB HD, so, not a problem. How would I run fsck on the SSD? The OS is running from it, can it be unmounted?
- Top
- Bottom
Comment
-
Doing a big copy - sudo iotop shows 94-99% in the IO category for command [jbd2/sdb1-8]. Read and write speeds for this command are 0%.
Below that there is a disk read speed 500-750 K/s and write speed 600-800 K/s for command kdeinit4: ki~.slave-socket. IO for that command is between .5-1%, peaking to 2.44%
- Top
- Bottom
Comment
-
/dev/sdb:
Model=ST31000524AS, FwRev=JC4B, SerialNo=6VPGWCVQ
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-4,5,6,7
* signifies the current active mode
Timing cached reads: 8938 MB in 2.00 seconds = 4472.47 MB/sec
Timing buffered disk reads: 290 MB in 3.01 seconds = 96.50 MB/sec
Done in the middle of a save from GIMP.
- Top
- Bottom
Comment
-
Originally posted by Jeremy_Ray View Post/dev/sdb:
Model=ST31000524AS, FwRev=JC4B, SerialNo=6VPGWCVQ
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1953525168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-4,5,6,7
* signifies the current active mode
Timing cached reads: 8938 MB in 2.00 seconds = 4472.47 MB/sec
Timing buffered disk reads: 290 MB in 3.01 seconds = 96.50 MB/sec
I'll get back to you if I can think of something else to test.
- Top
- Bottom
Comment
-
One other thing to try: do a copy (of a single large file) using rsync with the --progress parameter. Does the transfer speed stay fairly constant or does it oscillate between fast and slow? (I get about 22-25MB/s fairly steady, although on previous installations I've often had problems with transfers starting fast and then slowing to less than 3MB/s - and sometimes speeding up again randomly.)
How much RAM do you have?
The high io utilisation for [jbd2/sdb1-8] may be a suspect. This process or thread relates to ext4 journalling (a good thing to have, generally). I'm not sure what to do about it though ...
You might want to install smartmontools and run sudo smartctl -i /dev/sdb (or whatever the terabyte drive is).I'd rather be locked out than locked in.
- Top
- Bottom
Comment
Comment