[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20120725233859.GA6752@merlins.org>
Date: Wed, 25 Jul 2012 16:38:59 -0700
From: Marc MERLIN <marc@...lins.org>
To: Lukáš Czerner <lczerner@...hat.com>
Cc: tytso@....edu, linux-ext4@...r.kernel.org, axboe@...nel.dk,
Milan Broz <mbroz@...hat.com>
Subject: Re: du -s src is a lot slower on SSD than spinning disk in the same laptop
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists