[Top] [All Lists]

Re: [PATCH V2] xfs: truncate_setsize should be outside transactions

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH V2] xfs: truncate_setsize should be outside transactions
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sun, 4 May 2014 10:06:18 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140503151601.GB28608@xxxxxxxxxxxxx>
References: <1398983979-23696-1-git-send-email-david@xxxxxxxxxxxxx> <20140502045443.GA8867@xxxxxxxxxxxxx> <20140502050053.GA17578@xxxxxxxxxxxxx> <20140502064700.GB26353@dastard> <20140502070054.GC26353@dastard> <20140502100802.GB14028@xxxxxxxxxxxxx> <20140502232339.GD26353@dastard> <20140503151601.GB28608@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sat, May 03, 2014 at 08:16:01AM -0700, Christoph Hellwig wrote:
> On Sat, May 03, 2014 at 09:23:39AM +1000, Dave Chinner wrote:
> > before we get to the transaction that can fail:
> > block_truncate_page() zeroes the tail of the page cache page. Hence
> > if the transaction reservation fails, we've already trashed the file
> > data - we may as well finish off the job and at least make it look
> > like the truncate succeeded from a user point of view. They then get
> > a ENOMEM error (only non-fatal error that can come from
> > xfs_trans_reserve) and try the truncate again....
> I don't think we can even get the ENOMEM.

We can - we pass KM_MAYFAIL to xlog_ticket_alloc() from

> But yeah, I guess
> we want something like the old version, with comments explaining exactly
> we we have this order.

I'll send another version of the first patch with an expanded


Dave Chinner

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