|To:||David Chinner <dgc@xxxxxxx>|
|Subject:||Re: several messages|
|From:||Stephane Doyon <sdoyon@xxxxxxxxx>|
|Date:||Fri, 6 Oct 2006 09:03:03 -0400 (EDT)|
|Cc:||Trond Myklebust <trond.myklebust@xxxxxxxxxx>, xfs@xxxxxxxxxxx, nfs@xxxxxxxxxxxxxxxxxxxxx, Shailendra Tripathi <stripathi@xxxxxxxxx>|
|References:||<Pine.LNX.4.64.0609191533240.25914@xxxxxxxxxxxxxxxxxxxxx> <451A618B.5080901@xxxxxxxxx> <Pine.LNX.4.64.0610020939450.5072@xxxxxxxxxxxxxxxxxxxxx> <20061002223056.GN4695059@xxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0610030917060.31738@xxxxxxxxxxxxxxxxxxxxx> <20061005083015.GC19345@xxxxxxxxxxxxxxxxx> <Pine.LNX.4.64.0610051139540.31641@xxxxxxxxxxxxxxxxxxxxx> <20061005232935.GE19345@xxxxxxxxxxxxxxxxx>|
On Fri, 6 Oct 2006, David Chinner wrote:
The backtrace looked like this: ... nfsd_write nfsd_vfs_write vfs_writev do_readv_writev xfs_file_writev xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space xfs_flush_device schedule_timeout_uninterruptible.Ahhh, this gets hit on the ->prepare_write path (xfs_iomap_write_delay()),
not the allocate path (xfs_iomap_write_allocate()). Sorry - I got myself (and probably everyone else) confused there which why I suspected sync writes - they trigger the allocate path in the write call. I don't think 2.6.18 will change anything. FWIW, I don't think we can avoid this sleep when we first hit ENOSPC conditions, but perhaps once we are certain of the ENOSPC status we can tag the filesystem with this state (say an xfs_mount flag) and only clear that tag when something is freed. We could then use the tag to avoid continually trying extremely hard to allocate space when we know there is none available....
Yes! That's what I was trying to suggest :-). Thank you. Is that hard to do?
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: XFS filesystem structure document, Stewart Smith|
|Next by Date:||Re: several messages, Stephane Doyon|
|Previous by Thread:||Re: several messages, David Chinner|
|Next by Thread:||TAKE 956714 - inode scan speedup for subtree and incremental dumps, Bill Kendall|
|Indexes:||[Date] [Thread] [Top] [All Lists]|