On Wed, Jul 25, 2012 at 11:32:23PM -0400, Ted Ts'o wrote: > 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. I'm not very familiar with blktrace, but here is one run I did when I was trying to debug why dd of my dmcrypted FS was running at 27MB/s instead of 270MB/s. http://marc.merlins.org/tmp/blktrace.txt (dd shows up as 'bash' for some reason). If that format isn't good, can you tell me which blktrace command lines I should use to get you the exact output you'd like? 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
