On Fri, Mar 04, 2011 at 09:41:05AM +1100, Dave Chinner wrote: > On Thu, Mar 03, 2011 at 10:34:10AM -0500, Christoph Hellwig wrote: > > I still don't see any point in having the ENOSPC flushing moved to a > > different context. > > IIRC, stack usage has always been an issue, and we also call > xfs_flush_inodes() with the XFS_IOLOCK held (from > xfs_iomap_write_delay()) so the alternate context was used to avoid > deadlocks. I don't think we have that deadlock problem now thanks to > being able to combine SYNC_TRYLOCK | SYNC_WAIT flags, but I'm not > sure we can ignore the stack issues. Given that we wait for completion of the syncing in the caller moving it to a different context does not help with any deadlocks. It just makes them impossible to detect using lockdep. > I've also realised the work_pending() check is unnecessary, as is > the lock, because queue_work() will only queue new work if the work > item isn't already pending so there's no need to check it here. > Hence all this actually needs to do is: > > queue_work() > flush_work_sync() or in fact only use the writeback_inodes_sb_if_idle call you added later. That also causes writeback of data from the flusher threads. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
