4

Ever since I got my SSD (Crucial M4 - 256gb) I've had an issue that it would write as slow as running Windows 7 on a 486 whenever it's doing something with small files. I managed to "fix" this in Windows 7 by installing the Intel Rapid Storage Technology driver/service.

However, in Linux (running Ubuntu 13.04) there doesn't seem to be a driver for this. I've been trying a lot of different solutions and none of them seem to have worked so far.

My SSD is partitioned in one single EXT4 parition, mounted as /. I have a separate 2TB harddisk which I mount on /home

Here's some information I grabbed concerning the block-sizes:

# sudo blockdev --getbsz /dev/sda
> 4096

# sudo hdparm -I /dev/sda | grep -i physical
> Physical Sector size: 512 bytes

My fstab entry for my SSD looks like this:

UUID=c954288b-e1bd-4d3b-93ab-6a688210d070 /               ext4    errors=remount-ro,relatime,barrier=0,noatime,nodiratime,discard,commit=120  0       1

As you can see by the options, I've tried a lot of things, but none of them seem to work properly. To give an example: installing ViM using "apt-get install vim" took over 2 minutes.

A full apt-get dist-upgrade took over 4 and a half hour. I've been running Ubuntu on my normal HDD (5200 rpm) and it goes A LOT faster than this.

According to parted, my partition is aligned properly. I've checked using the following commands:

# sudo parted /dev/sda
<parted> align-check opt
partition: 1

> aligned 1

Also, when running iotop whenever the SSD gets "busy", I see jbd2 non-stop consuming about 99~100% of the time.

If anyone could shine some light on this issue, that would be totally awesome!

edit: Some extra info:

Running hdparm -t /dev/sda gives the following output (which looks totally fine to me)

Timing buffered disk reads: 680 MB in  3.01 seconds = 226.16 MB/sec

iotop output when idle:

TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                                                                                               
 2346 be/4 harold      0.00 B/s   31.04 K/s  0.00 %  0.00 % chrome
    1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init
    2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
    3 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
    5 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/0:0H]
    7 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/u:0H]

Sometimes when running installations of applications or other heavy things, this process "jbd2" kicks in eating up all the resources, while the actualy application running (e.g. mysqld updating some database related things or apt-get installing or updating software, remain at around 3~4%)

The strange part is, sometimes its working just fine (I've tried to reproduce the issue to post the results here, but apperantly it's happening at random times). I'll update the output of iotop below with results of when it's going wrong again.

I feel like my computer is trolling me now :(

edit2: Forgot to add some extras (thanks Craig Watson)

The contents of my /etc/rc.local file look like this:

echo deadline > /sys/block/sda/queue/scheduler
fstrim -v /
exit 0

And inside /etc/default/grub, I got:

GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline"

After first trying the scheduler, I've added the fstrim part as well because I still didn't get any good results with just the scheduler.

Thanks in advance.

Harold.

Improve this question
2
  • Just a sanity check, what makes you think the time is spent on disk IO rather than, say, network traffic? Your apt-get calls could be immensely slow if your network is hobbled for some reason, for example.
    – ChrisInEdmonton
    Jul 24, 2013 at 19:48
  • The downloading of the files is incredibly fast actually. It's the "unpacking" part that's really slow :(
    – Harold
    Jul 24, 2013 at 19:50

1 Answer 1

Reset to default
1

Try changing your I/O scheduler:

sudo echo deadline > /sys/block/sda/queue/scheduler

Then add it to the Grub defaults so that it loads on-boot:

sudo nano /etc/default/grub

Change GRUB_CMDLINE_LINUX_DEFAULT to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=deadline"

And run: sudo update-grub2

Also check your RAM usage - you could be swapping to your SSD, which (in the long run) might have bad effects. If you've got enough RAM, you can set swappiness to zero so that RAM won't be used unless you're completely out of RAM:

sudo echo 0 > /proc/sys/vm/swappiness

Reference: http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm

Improve this answer
2
  • Thanks for the reply. I've actually tried that as well (completely forgot to post that, I'll update the post). I have the scheduler in my rc.local file and also using "fstrim -v /" (after the scheduler proved itself not to be working either at times).
    – Harold
    Jul 24, 2013 at 20:20
  • Memory output looks fine as well. Out of 8 gigs, there's 3.4 in use, 4.6 free. Swap area is also 8 gig, 0 in use.
    – Harold
    Jul 24, 2013 at 20:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .