[Top] [All Lists]

Re: XFS hang during xfs_fsr run

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS hang during xfs_fsr run
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 12 Mar 2010 09:27:37 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, Michael Weissenbacher <mw@xxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20100312115645.GD4732@dastard>
References: <20100304222611.GK14317@xxxxxxxxxxxxxxxx> <4B92C71C.5010003@xxxxxxxxxxxx> <20100308000601.GF28189@xxxxxxxxxxxxxxxx> <4B94EADD.2080108@xxxxxxxxxxxx> <4B953D3F.3090002@xxxxxxxxxxx> <4B975C5C.5090806@xxxxxxxxxxxx> <20100311233934.GB4732@dastard> <4B9A0D2F.30506@xxxxxxxxxxxx> <20100312100019.GA13230@xxxxxxxxxxxxx> <20100312115645.GD4732@dastard>
User-agent: Mutt/1.5.19 (2009-01-05)
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.

<Prev in Thread] Current Thread [Next in Thread>