On Thu, Sep 27, 2012 at 08:49:15AM -0400, Josef 'Jeff' Sipek wrote: > On Tue, Apr 24, 2012 at 09:27:59AM +1000, Dave Chinner wrote: > ... > > So, yes, your hangs are definitely due to inode buffer RMW cycles > > when trying to flush dirty inodes from the cache. I have a few > > ideas on how to fix this - but I'm not sure whether a current TOT > > solution will be easily back-portable. The simplest solution is a > > readahead based solution - AIL pushing is async, and will cycle back > > to inodes that it failed to flush the first time past, so triggering > > readahead on the first pass might work just fine. > > Have you had time to look at this? No. > (We got bitten by this again and I > really don't want to go back to ext4.) Is there anything I can help with? What is needed is a xfs_inode_readahead function(), which takes an xfs inode and attempts to issue readahead on the underlying buffer if it is not found in cache. The simplest thing to do is add another flag to xfs_buf_read that is passed through from xfs_iflush() to say "don't block on read". Indeed, we used to have a XBF_DONT_BLOCK flag that we removed recently becuse it was the default behaviour for everything. That could be reintroduced to tell xfs_buf_read_map() that it should return the bufer if it is in cache, or issue readahead and return null if it is not found in memory so that a read a little while later might find it. COmbined iwth the XBF_TRYLOCK that xfs_iflush alrady uses, it won't block on read IO already in progress, either. i.e. there's a difference between not-in-cache and in-cache-but-locked when it comes to issuing readahead, so there might need to be slight changes to xfs_buf_find() to accomodate that. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
