From: Alberto Bertogli <albertito@blitiri.com.ar>
To: Theodore Tso <tytso@mit.edu>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
dm-devel@redhat.com
Subject: Re: jbd2 inside a device mapper module
Date: Sat, 27 Dec 2008 01:00:20 -0200 [thread overview]
Message-ID: <20081227030020.GD4127@blitiri.com.ar> (raw)
In-Reply-To: <20081226180642.GO9871@mit.edu>
On Fri, Dec 26, 2008 at 01:06:42PM -0500, Theodore Tso wrote:
> On Fri, Dec 26, 2008 at 02:17:08PM -0200, Alberto Bertogli wrote:
> >
> > At this moment I'm trying to keep it simple, so I plan to batch two for
> > each sector written to the device: one for the metadata and one for the
> > data.
> >
>
> I think I can pretty much guarantee that your performance will be so
> horrible that it won't be worth using.
Thanks for the warning.
I have a couple of alternatives in mind, the most decent one at the
moment is having two metadatas (M1 and M2) for the each block, and
update M1 on the first write to the given block, M2 on the second, M1 on
the third, and so on.
So, if a block has written "A" and M1 holds crc("A"), and the user wants
to write "B" to the block, I would first write crc("B") in M2, and then
write "B" to the block.
The biggest problem I can see with this approach is that I require
either a timestamp on the metadata so I can determine where to write (if
M1 or M2).
And I'm not sure if it'd perform better than the journal, tho.
Do you have any suggestions as to how can I handle this issue?
> > > Yes, this is necessary because in a production system you need to be
> > > able to identify the external journal by UUID, and the ext2/3/4
> > > superblock makes it easy to add a label, UUID, et. al. It also
> > > significantly lowers the chance that an external journal will get
> > > misidentified as some other filesystem based on the data stored in the
> > > journal.
> >
> > Yes, it makes sense. I've reserved the first sector for that purpose.
>
> Why not just use the ext3/4 external journal format?
Wouldn't that lead to confusion, because people can think the device
holds an ext3/4 external journal, while it actually holds a
device-mapper backing device that happens to contain a journal?
What would be the advantages of using the ext3/4 journal format, over a
simple initial sector and the journal following?
Thanks,
Alberto
next prev parent reply other threads:[~2008-12-27 3:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20081224211038.GT4127@blitiri.com.ar>
2008-12-24 22:38 ` jbd2 inside a device mapper module Alberto Bertogli
[not found] ` <20081224234915.GA23723@mit.edu>
2008-12-25 14:35 ` Alberto Bertogli
2008-12-25 15:52 ` Theodore Tso
2008-12-26 0:00 ` Alberto Bertogli
2008-12-26 3:37 ` Theodore Tso
2008-12-26 16:17 ` Alberto Bertogli
2008-12-26 18:06 ` Theodore Tso
2008-12-27 3:00 ` Alberto Bertogli [this message]
2008-12-27 19:29 ` Theodore Tso
2008-12-29 21:30 ` Alberto Bertogli
2008-12-27 20:01 ` Andreas Dilger
[not found] ` <46A00B48CC54E4468EF6911F877AC4CA01DDBB66@blrx3m10.blr.amer.dell.com>
2008-12-29 21:05 ` [dm-devel] " Alberto Bertogli
2008-12-30 6:55 ` Alex Tomas
2008-12-30 13:51 ` Alberto Bertogli
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=20081227030020.GD4127@blitiri.com.ar \
--to=albertito@blitiri.com.ar \
--cc=dm-devel@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox