Re: XFS hang during xfs_fsr run

[Dave Chinner <david@fromorbit.com>]

On Fri, Mar 12, 2010 at 09:27:37AM -0500, Christoph Hellwig wrote:
> On Fri, Mar 12, 2010 at 10:56:45PM +1100, Dave Chinner wrote:
> > ->page_mkwrite executes without the inode iolock held, so we can't
> > lock it out from creating new delalloc pages by holding the iolock
> > like the bmap code does.
> > 
> > I don't think we're allowed to take the iolock in ->page_mkwrite, so
> > effectively that leaves us with the situation where we can't do an
> > atomic flush and map in the bmap code.
> > 
> > Christoph, I guess that means we need to make the bmap code
> > handle/ignore delalloc extents rather than assume they never occur
> > after the flush.  What do you think?
> 
> The current swapext code is supposed to skip any file that is mapped
> into userspace via mmap.  So if you get a file that is actually mmaped
> something is wrong with that check.  From a quick look the only problem
> I see is that we don't take the iolock in ->mmap so we could add a new
> mapping after the check, but I'd be surprise if that is what Michael
> is seeing.

The swapext mmap check occurs a long time after we actually get the
extents from the file, so while the swapext will fail that check,
we're not getting to it. i.e. we're assert failing during the setup
for the data move before we do the swapext. Perhaps we should make
xfs_getbmap() return EBUSY for mmap()d files like swapext does?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs