From: Jan Kara <jack@suse.cz>
To: ocfs2-devel@oss.oracle.com, mfasheh@suse.com,
linux-ext4@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Subject: Re: [Ocfs2-devel] [PATCH 01/18] jbd2: Add buffer triggers
Date: Fri, 19 Dec 2008 01:40:05 +0100 [thread overview]
Message-ID: <20081219004005.GG8424@duck.suse.cz> (raw)
In-Reply-To: <20081219003224.GC21870@mail.oracle.com>
On Thu 18-12-08 16:32:25, Joel Becker wrote:
> On Thu, Dec 18, 2008 at 07:08:21PM +0100, Jan Kara wrote:
> > > On Tue, Dec 09, 2008 at 05:09:38PM -0800, Joel Becker wrote:
> > > > Filesystems often to do compute intensive operation on some
> > > > metadata. If this operation is repeated many times, it can be very
> > > > expensive. It would be much nicer if the operation could be performed
> > > > once before a buffer goes to disk.
> > >
> > > I realized, well, that I'm an idiot. The previous patch has a
> > > significant bug: what if a block is deallocated, then reused as a
> > > different type of metadata, all before the committing transaction gets
> > > around to firing the triggers? It could use the new block type's
> > > triggers against the b_frozen_data of the old block type.
> > > The easy answer is to add b_frozen_triggers alongside
> > > b_frozen_data. Here's the new patch.
> > I think this is a reasonable thing to do, although I'm not sure it can
> > really happen - at least ext3 uses a mechanism that does not allow
> > reusing a freed block in the same transaction (because otherwise there's
> > no way of recovering unjournaled data after crash).
>
> Oh, frozen_data protects that sort of thing. The concern is
> that the old block type is in the committing transaction, and the new
> block type is in the running transaction. But the trigger type is from
> the new block type, and not valid to call against the committing block
> in the committing transaction.
Sorry, I've confused frozen_data with committed_data. Buffer with
frozen_data happens quite often. So your fix is really needed.
> > > diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
> > > index ebc667b..c8a1bac 100644
> > > --- a/fs/jbd2/commit.c
> > > +++ b/fs/jbd2/commit.c
> > > @@ -509,6 +509,10 @@ void jbd2_journal_commit_transaction(journal_t *journal)
> > > if (is_journal_aborted(journal)) {
> > > clear_buffer_jbddirty(jh2bh(jh));
> > > JBUFFER_TRACE(jh, "journal is aborting: refile");
> > > + jbd2_buffer_abort_trigger(jh,
> > > + jh->b_frozen_data ?
> > > + jh->b_frozen_triggers :
> > > + jh->b_triggers);
> > Wouldn't it be nicer if the jbd2_buffer_foo_trigger() functions
> > checked which set of triggers they should use and used it?
>
> Well, it only does on the frozen-data check. I suppose that
> could be pulled into the abort_trigger() function. Maybe an additional
> patch?
Yeah, I was just wondering why we don't do:
jbd2_buffer_abort_trigger(jh)
and choose the proper set of triggers in the jbd2_buffer_abort_trigger()
function (and similarly for the commit trigger). Or does it make sence
to not call frozen trigger in some place if there're frozen data set?
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: ocfs2-devel@oss.oracle.com, mfasheh@suse.com,
linux-ext4@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Subject: [Ocfs2-devel] [PATCH 01/18] jbd2: Add buffer triggers
Date: Fri, 19 Dec 2008 01:40:05 +0100 [thread overview]
Message-ID: <20081219004005.GG8424@duck.suse.cz> (raw)
In-Reply-To: <20081219003224.GC21870@mail.oracle.com>
On Thu 18-12-08 16:32:25, Joel Becker wrote:
> On Thu, Dec 18, 2008 at 07:08:21PM +0100, Jan Kara wrote:
> > > On Tue, Dec 09, 2008 at 05:09:38PM -0800, Joel Becker wrote:
> > > > Filesystems often to do compute intensive operation on some
> > > > metadata. If this operation is repeated many times, it can be very
> > > > expensive. It would be much nicer if the operation could be performed
> > > > once before a buffer goes to disk.
> > >
> > > I realized, well, that I'm an idiot. The previous patch has a
> > > significant bug: what if a block is deallocated, then reused as a
> > > different type of metadata, all before the committing transaction gets
> > > around to firing the triggers? It could use the new block type's
> > > triggers against the b_frozen_data of the old block type.
> > > The easy answer is to add b_frozen_triggers alongside
> > > b_frozen_data. Here's the new patch.
> > I think this is a reasonable thing to do, although I'm not sure it can
> > really happen - at least ext3 uses a mechanism that does not allow
> > reusing a freed block in the same transaction (because otherwise there's
> > no way of recovering unjournaled data after crash).
>
> Oh, frozen_data protects that sort of thing. The concern is
> that the old block type is in the committing transaction, and the new
> block type is in the running transaction. But the trigger type is from
> the new block type, and not valid to call against the committing block
> in the committing transaction.
Sorry, I've confused frozen_data with committed_data. Buffer with
frozen_data happens quite often. So your fix is really needed.
> > > diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
> > > index ebc667b..c8a1bac 100644
> > > --- a/fs/jbd2/commit.c
> > > +++ b/fs/jbd2/commit.c
> > > @@ -509,6 +509,10 @@ void jbd2_journal_commit_transaction(journal_t *journal)
> > > if (is_journal_aborted(journal)) {
> > > clear_buffer_jbddirty(jh2bh(jh));
> > > JBUFFER_TRACE(jh, "journal is aborting: refile");
> > > + jbd2_buffer_abort_trigger(jh,
> > > + jh->b_frozen_data ?
> > > + jh->b_frozen_triggers :
> > > + jh->b_triggers);
> > Wouldn't it be nicer if the jbd2_buffer_foo_trigger() functions
> > checked which set of triggers they should use and used it?
>
> Well, it only does on the frozen-data check. I suppose that
> could be pulled into the abort_trigger() function. Maybe an additional
> patch?
Yeah, I was just wondering why we don't do:
jbd2_buffer_abort_trigger(jh)
and choose the proper set of triggers in the jbd2_buffer_abort_trigger()
function (and similarly for the commit trigger). Or does it make sence
to not call frozen trigger in some place if there're frozen data set?
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2008-12-19 0:40 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-10 1:09 [Ocfs2-devel] [PATCH 0/18] ocfs2: Add metadata ECC - almost there Joel Becker
2008-12-10 1:09 ` [PATCH 01/18] jbd2: Add buffer triggers Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] " Joel Becker
2008-12-11 19:57 ` Andreas Dilger
2008-12-13 0:45 ` Joel Becker
2008-12-13 0:45 ` [Ocfs2-devel] " Joel Becker
2008-12-18 18:08 ` Jan Kara
2008-12-18 18:08 ` Jan Kara
2008-12-19 0:32 ` Joel Becker
2008-12-19 0:32 ` [Ocfs2-devel] " Joel Becker
2008-12-19 0:40 ` Jan Kara [this message]
2008-12-19 0:40 ` Jan Kara
2008-12-19 1:43 ` Joel Becker
2008-12-19 1:43 ` [Ocfs2-devel] " Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 02/18] ocfs2: Add the on-disk structures for metadata checksums Joel Becker
2008-12-10 1:32 ` Tao Ma
2008-12-10 1:40 ` Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 03/18] ocfs2: Add the underlying blockcheck code Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 04/18] ocfs2: Add a validation hook for quota block reads Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 05/18] ocfs2: block read meta ecc Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 06/18] ocfs2: Add journal_access functions with jbd2 triggers Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 07/18] ocfs2: Wrap up the common use cases of ocfs2_new_path() Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 08/18] ocfs2: Use metadata-specific ocfs2_journal_access_*() functions Joel Becker
2008-12-10 2:31 ` Tao Ma
2008-12-10 11:15 ` Joel Becker
2008-12-11 0:31 ` Tao Ma
2008-12-11 0:46 ` Joel Becker
2008-12-11 1:10 ` Tao Ma
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 09/18] ocfs2: Add ecc and checksums to ocfs2 xattr buckets Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 10/18] ocfs2: Create ocfs2_xattr_value_buf Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 11/18] ocfs2: Pull ocfs2_xattr_value_buf up from __ocfs2_remove_xattr_range() Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 12/18] ocfs2: Pull ocfs2_xattr_value_buf up into ocfs2_xattr_value_truncate() Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 13/18] ocfs2: Pass ocfs2_xattr_value_buf " Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 14/18] ocfs2: Pass value buf to ocfs2_xattr_update_entry() Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 15/18] ocfs2: Use ocfs2_xattr_value_buf in ocfs2_xattr_set_entry() Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 16/18] ocfs2: Pass value buf to ocfs2_remove_value_outside() Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 17/18] ocfs2: Use proper journal_access function in xattr.c Joel Becker
2008-12-10 1:09 ` [Ocfs2-devel] [PATCH 18/18] ocfs2: Enable metadata checksums Joel Becker
2008-12-10 1:52 ` [Ocfs2-devel] [PATCH 0/18] ocfs2: Add metadata ECC - almost there Joel Becker
2008-12-10 12:54 ` Andi Kleen
2008-12-10 18:15 ` Joel Becker
2008-12-10 19:27 ` Andi Kleen
2008-12-11 2:16 ` Joel Becker
2008-12-11 2:25 ` [Ocfs2-devel] [PATCH] ocfs2: Add directory block trailers Joel Becker
2008-12-11 2:25 ` [Ocfs2-devel] [PATCH] ocfs2: Checksum and ECC for directory blocks Joel Becker
2008-12-11 2:46 ` [Ocfs2-devel] [PATCH 0/18] ocfs2: Add metadata ECC - almost there Tao Ma
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=20081219004005.GG8424@duck.suse.cz \
--to=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=mfasheh@suse.com \
--cc=ocfs2-devel@oss.oracle.com \
--cc=tytso@mit.edu \
/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.