Performance problem - reads slower than writes

Christoph Hellwig hch at infradead.org
Tue Jan 31 08:52:05 CST 2012


On Tue, Jan 31, 2012 at 10:31:26AM +0000, Brian Candler wrote:
> - seek to inode (if the inode block isn't already in cache)
> - seek to extents table (if all extents don't fit in the inode)
> - seek(s) to the file contents, depending on how they're fragmented.
> 
> I am currently seeing somewhere between 7 and 8 seeks per file read, and
> this just doesn't seem right to me.

You don't just read a single file at a time but multiple ones, don't
you?

Try playing with the following tweaks to get larger I/O to the disk:

 a) make sure you use the noop or deadline elevators
 b) increase /sys/block/sdX/queue/max_sectors_kb from its low default
 c) dramatically increase /sys/devices/virtual/bdi/<major>:<minor>/read_ahead_kb

> OK. I saw "df -i" reporting a stupid number of available inodes, over 500
> million, so I decided to reduce it to 100 million.  But df -k didn't show
> any corresponding increase in disk space, so I'm guessing in xfs these are
> allocated on-demand, and the inode limit doesn't really matter?

Exactly, the number displayed is the upper bound.



More information about the xfs mailing list