xfs
[Top] [All Lists]

Re: [PATCH] log replay should not overwrite newer ondisk inodes

To: David Chinner <dgc@xxxxxxx>
Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes
From: David Chinner <dgc@xxxxxxx>
Date: Wed, 5 Sep 2007 09:51:39 +1000
Cc: Shailendra Tripathi <stripathi@xxxxxxxxx>, Lachlan McIlroy <lachlan@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <20070904234926.GI734179@xxxxxxx>
References: <46D6279F.40601@xxxxxxx> <46DDE4A2.1070204@xxxxxxxxx> <20070904234926.GI734179@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Wed, Sep 05, 2007 at 09:49:26AM +1000, David Chinner wrote:
> On Tue, Sep 04, 2007 at 04:05:06PM -0700, Shailendra Tripathi wrote:
> > Hi,
> >      Can someone explain how not checking the flushiter can losse 
> > filesize updates.
> > Let me the take the case mentioned here in the fix statement:
> > 
> > a. Clustered inode create -  flush iter - X( 0)
> > b. size update  --> flush iter --> Y
> > 
> > X and Y will always hold as: X <= Y, that is, it is not possible to have 
> > X >Y (unless size update is non -transactional. As far as I know, size 
> > update is always transactional.)
> 
> Size updates are not transactional. They are accidentally logged in

s/accidentally/intentionally/

> other transactions (e.g. truncates) but size updates due to data
> writes are never logged. When we write an inode, we take the latest
> in memory size and write it to disk without logging that change
> so we can't rely on log recovery to get it right simply by replaying
> transactions.
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> Principal Engineer
> SGI Australian Software Group

-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


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