Re: several messages

[Stephane Doyon <sdoyon@xxxxxxxxx>]

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()),
Yes.

> 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?