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. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
