[Top] [All Lists]

Re: [RFC PATCH 07/11] xfs: retry trans reservation on ENOSPC in xfs_inac

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [RFC PATCH 07/11] xfs: retry trans reservation on ENOSPC in xfs_inactive()
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Fri, 06 Sep 2013 07:30:00 -0400
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130906001718.GQ12779@dastard>
References: <1378232708-57156-1-git-send-email-bfoster@xxxxxxxxxx> <1378232708-57156-8-git-send-email-bfoster@xxxxxxxxxx> <20130905014016.GU23571@dastard> <5228AED7.1010700@xxxxxxxxxx> <20130906001718.GQ12779@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8
On 09/05/2013 08:17 PM, Dave Chinner wrote:
> On Thu, Sep 05, 2013 at 12:18:31PM -0400, Brian Foster wrote:
>> On 09/04/2013 09:40 PM, Dave Chinner wrote:
>>> On Tue, Sep 03, 2013 at 02:25:04PM -0400, Brian Foster wrote:
>>>> An ifree data block reservation can fail with ENOSPC. Flush inodes
>>>> to try and free up space or attempt without a data block
>>>> reservation to avoid failing out of xfs_inactive().
>>>> Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
>>>> ---
>>>>  fs/xfs/xfs_inode.c | 11 +++++++++++
>>>>  1 file changed, 11 insertions(+)
>> Subsequent to avoiding that, I
>> believe there were inconsistent fs issues called out due to the unlinked
>> lists being populated after umount.
> That sounds like a recovery failure, not so much an ENOSPC failure.
> i.e. that recovery only looks at the log to see if it's clean, and
> only recovers unlinked lists if it's dirty. There is the
> *possibility* of having a clean log with inodes on the unlinked
> list, and log recovery doesn't run the unlinked list processing in
> that case.

Interesting, I'll have a closer look when I rework the inactive
transaction reservation bits. Thanks.


> This is one of the issues we'll need to fix for O_TMPFILE support
> as it will actively use inodes on unlinked list for potentially long
> periods of time.
>> Taking a further look, I missed the XFS_TRANS_RESERVE flag and whole
>> m_resblks mechanism. I'll take a closer look at that and see if that
>> works to resolve the problem instead of the flush.
> It should - the only time it won't is if we exhaust the pool, but
> that doesn't happen in normal ENOSPC situations and any blocks we do
> end up freeing will immediately refill the reserve pool...
> Cheers,
> Dave.

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