Re: du -s src is a lot slower on SSD than spinning disk in the same laptop

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 25, 2012 at 08:40:28PM +0200, Lukáš Czerner wrote:
> yesterday Milan Broz pointed me to the other problem of yours where
> by reading from dm_crypt target on the SSD was much slower than on
> the spinning disk. I am not sure if he already shared some
> information he managed to gather, but we saw that reading from SSD
> was much slower probably because reads were divided into tons of
> small (page size) bios as opposed to bigger chunks on spinning
> disk.
 
Yes, indeed. To make things simpler, I'm not using dmcrypt here.

> This is probably the same reason here. The reason is most likely
> that we handle SSD differently than spinning disk (turn off
> elevator, different io scheduler and possibly other things I am not
> aware of). Also IIRC bio merging should be less "aggressive" on SSD
> than spinning disk (or maybe even turned off?), because SSD should
> supposedly handle much more iops than than spinning drive, hence
> waiting for a merge might slow things down. However in this case it
> seems to have quite opposite effect for some reason.
> 
> You may try to convince kernel to treat your SSD as rotational disk
> by:
> 
> echo 1 > /sys/block/sda/queue/rotational
> and see if it improves things.

Actually I had done that, along with making the readahead 8K change, but
that didn't help:

gandalfthegreat:/mnt/mnt2# time du -sh src/
519M	src/
real	0m12.176s
gandalfthegreat:/mnt/mnt2# df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        25G  3.0G   21G  13% /mnt/mnt2
gandalfthegreat:/mnt/mnt2# blockdev --report /dev/sda2
RO    RA   SSZ   BSZ   StartSec            Size   Device
rw  8192   512  4096     502272     26843283456   /dev/sda2
gandalfthegreat:/mnt/mnt2# cat /sys/block/sda/queue/rotational
1
gandalfthegreat:/mnt/mnt2# 

> Unfortunately I think that there is not much we can do about this
> from the file system level. Someone from block level should
> definitely take a look at this issue. Jens ?

Ok, I just wanted to rule out that it was not a VFS issue.
If you're confident it's block level and basically having storage that is
too fast (and indeed, I just bought one of the fastest SSDs out there) is
actually causing problems that make the entire system much slower as a
result, I'm happy to take it up another list.

Where would you recommend I go with this?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux