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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Jul 2012 23:32:23 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Lukáš Czerner <lczerner@...hat.com>
Cc:	Marc MERLIN <marc@...lins.org>, 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:
> > First, I had he problem with btrfs (details below), and then I noticed that
> > while ext4 is actually twice as fast as btrfs, it's still a lot slower at
> > stat on my fast Samsung 830 512G SSD than my 1TB laptop hard drive (both
> > drives being in the same thinkpad T530 with 3.4.4 kernel).
> > 
> > How can things be so slow? 12-13 seconds to scan 15K inodes on a freshly
> > made filesystem (and 22 secs with btrfs, so at least ext4 wins). The same
> > thing on my spinning drive takes fewer than 4 seconds, and SSD should be
> > several times faster than that.
> > SSD throughput was measured over 400MB/s on the raw device and 268MB/s
> > through the filesystem:

Was this an identical file system image on HDD and SSD?

The obvious thing to do is to get a blktrace of du -sh w/ a cold cache
for both the HDD and SSD.  Regardless of whether it's something we can
address at the fs level, or in the block device layer, the blktrace
should make it really clear what is going on.

       	       	      	    	    - Ted
--
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