| To: | Dave Chinner <david@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: task blocked for more than 120 seconds |
| From: | "Josef 'Jeff' Sipek" <jeffpc@xxxxxxxxxxxxxx> |
| Date: | Thu, 27 Sep 2012 08:49:15 -0400 |
| Cc: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20120423232759.GO9541@dastard> |
| References: | <20120418151139.GC4652@xxxxxxxxxxxxxxxxxxxxxx> <20120418234821.GR6734@dastard> <20120419154601.GB8230@xxxxxxxxxxxxxxxxxxxxxx> <20120419225603.GA9541@dastard> <20120420135820.GB9189@xxxxxxxxxxxxxxxxxxxxxx> <20120421002932.GG9541@dastard> <20120423202441.GD21260@xxxxxxxxxxxxxxxxxxxxxx> <20120423232759.GO9541@dastard> |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
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? (We got bitten by this again and I really don't want to go back to ext4.) Is there anything I can help with? Jeff. -- Evolution, n.: A hypothetical process whereby infinitely improbable events occur with alarming frequency, order arises from chaos, and no one is given credit. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | more efficient way to print out inode->block mappings?, Linda Walsh |
|---|---|
| Next by Date: | [PATCH v2] xfsprog: remove duplicate vector memalign from xfs_io, Mark Tinguely |
| Previous by Thread: | more efficient way to print out inode->block mappings?, Linda Walsh |
| Next by Thread: | Re: task blocked for more than 120 seconds, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |