From: David Chinner <dgc@sgi.com>
To: Lachlan McIlroy <lachlan@sgi.com>
Cc: Timothy Shimmin <tes@sgi.com>,
Shailendra Tripathi <stripathi@agami.com>,
xfs-dev <xfs-dev@sgi.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes
Date: Wed, 5 Sep 2007 16:54:07 +1000 [thread overview]
Message-ID: <20070905065407.GO734179@sgi.com> (raw)
In-Reply-To: <46DE0906.2040602@sgi.com>
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
prev parent reply other threads:[~2007-09-05 6:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-30 2:12 [PATCH] log replay should not overwrite newer ondisk inodes Lachlan McIlroy
2007-08-30 4:31 ` Timothy Shimmin
2007-08-30 4:50 ` Lachlan McIlroy
2007-08-30 8:29 ` Timothy Shimmin
2007-08-30 8:51 ` Timothy Shimmin
2007-08-31 2:22 ` Lachlan McIlroy
2007-08-31 4:01 ` Mark Goodwin
2007-08-31 15:48 ` David Chinner
2007-09-02 22:50 ` Vlad Apostolov
2007-09-03 8:49 ` David Chinner
2007-09-07 2:03 ` Lachlan McIlroy
2007-09-07 14:05 ` David Chinner
2007-09-10 4:43 ` Lachlan McIlroy
2007-08-31 2:14 ` Lachlan McIlroy
2007-08-30 14:02 ` David Chinner
2007-09-04 23:05 ` Shailendra Tripathi
2007-09-04 23:49 ` David Chinner
2007-09-04 23:51 ` David Chinner
2007-09-05 1:19 ` Timothy Shimmin
2007-09-05 1:40 ` Lachlan McIlroy
2007-09-05 6:54 ` David Chinner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070905065407.GO734179@sgi.com \
--to=dgc@sgi.com \
--cc=lachlan@sgi.com \
--cc=stripathi@agami.com \
--cc=tes@sgi.com \
--cc=xfs-dev@sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.