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

David Chinner
2007-09-05T06:54:22Z

On Wed, Sep 05, 2007 at 11:40:22AM +1000, Lachlan McIlroy wrote:
> >Dave answered this but yes this is a case where we are breaking
> >the transaction model IMO. And my understanding is that we are doing
> >this for performance reasons.
> >One of Lachlan's proposals (IIRC) was to log the size change before the
> >ondisk size change in xfs_aops.c/xfs_setfilesize()
> >and thus follow the model but questions were raised about introducing
> >performance overhead of log traffic in the write path.
>
> It would make life easier to do it that way - we wouldn't have to check
> the flushiter field of the ondisk inode because we know we will end up
> with the same thing by just replaying the log. But since the addition
> of the flushiter stuff pre-dates the NULL files changes there must be
> another reason we need it. Previously the size change would get logged
> with an extent allocation transaction but extending a file within the
> same last block would not send the new file size to the log. I think
> that may have been the reason for needing the flushiter stuff. If we
> log the file size change in xfs_setfilesize() we may not need the
> flushiter stuff at all, hmmm maybe for timestamp updates?

atime, size updates and inode version format conversion may be written without
a transaction first logging the change.

Cheers,

Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group