[Top] [All Lists]

Re: page discard on page error

To: Mike Gao <ygao.linux@xxxxxxxxx>
Subject: Re: page discard on page error
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 19 Aug 2010 01:50:43 +1000
Cc: xfs@xxxxxxxxxxx, hch@xxxxxx
In-reply-to: <AANLkTimHBE_9pD1wWOkryOnqBgL2bJQTKoe52wYjfNw3@xxxxxxxxxxxxxx>
References: <AANLkTimHBE_9pD1wWOkryOnqBgL2bJQTKoe52wYjfNw3@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Wed, Aug 18, 2010 at 09:27:55AM -0500, Mike Gao wrote:
> Hi, all,
> I sync latest XFS last month and build into our embedded system. When I
> test, I found below issue.
> It seems that the xfs_iomap failed when it did allocat with
> xfs_ilock_nowait().
> I debug this and found that ip->i_lock is locked and there are sometime no
> unlock coming between two lock trying.
> This issue will give wrong data in file on disk exactly on that offset.

Ah, it looks like we dropped the EAGAIN error from xfs_map_blocks()
on the floor.

Christoph, the 2.6.34 code did this:

         * If it's delalloc and we have nowhere to put it,
         * throw it away, unless the lower layers told
         * us to try again.
        if (err != -EAGAIN) {
                if (!unmapped)

and the caller redirtied the page on EAGAIN. The EAGAIN comes from
the BMAPI_TRYLOCK case, so it is a valid return indicating that we
would have blocked on a non-blocking IO.

The current code does not handle EAGAIN at all, just discards the
page. This looks incorrect - I think that EAGAIN should still cause
the page to be redirtied, not discarded. I'm not sure if I missed
something else, though - can you remember why you removed the EAGAIN


Dave Chinner

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