From: Andreas Dilger <adilger@clusterfs.com>
To: Andrew Morton <akpm@zip.com.au>
Cc: Alexander Viro <viro@math.psu.edu>,
lkml <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [patch] ext2_fill_super breakage
Date: Thu, 28 Mar 2002 22:14:20 -0700 [thread overview]
Message-ID: <20020329051420.GO21133@turbolinux.com> (raw)
In-Reply-To: <3CA356AE.2E61F712@zip.com.au> <Pine.GSO.4.21.0203281838310.25746-100000@weyl.math.psu.edu> <3CA3B48F.25F9042D@zip.com.au>
On Mar 28, 2002 16:25 -0800, Andrew Morton wrote:
> BTW, ext3 keeps a kdev_t on-disk for external journals. The
> external journal support is experimental, added to allow people
> to evaluate the usefulness of external journalling. If we
> decide to retain the capability we'll be moving it to a UUID
> or mount-based scheme. So if the kdev_t is being a problem,
> I think we can just break it.
Actually, I believe it would be keeping a "dev_t" on the disk, so
if we are using it from within the kernel we should be using
"to_kdevt()" or whatever the function is called.
That reminds me - I _do_ have the mount-based stuff for journal
devices set up. At fs mount time, the ext3 code calls a helper
function which will locate the journal by its UUID. The only
real reason for the s_journal_dev might be for e2fsck to locate
the journal device more easily, but it is also pretty easy to
find the journal by UUID in user space.
I'm just woefully behind on getting patches out of my tree. At least
with my OLS paper I'm "forced" to finish off the ext3 online resizing
code within the next 3 months or so.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
next prev parent reply other threads:[~2002-03-29 5:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-28 7:30 [patch] ext2_fill_super breakage Andrew Morton
2002-03-28 13:34 ` Brian Gerst
2002-03-28 13:46 ` Rob Landley
2002-03-28 13:50 ` Jos Hulzink
2002-03-28 17:26 ` Bill Davidsen
2002-03-28 17:27 ` Andrew Morton
2002-03-28 18:13 ` Brian Gerst
2002-03-28 14:21 ` Alexander Viro
2002-03-28 14:36 ` Nikita Danilov
2002-03-28 14:48 ` Alexander Viro
2002-03-28 14:51 ` Nikita Danilov
2002-03-28 15:20 ` Alexander Viro
2002-03-28 14:50 ` Arjan van de Ven
2002-03-28 15:01 ` Nikita Danilov
2002-03-28 17:45 ` Andrew Morton
2002-03-28 23:51 ` Alexander Viro
2002-03-29 0:25 ` Andrew Morton
2002-03-29 5:14 ` Andreas Dilger [this message]
2002-03-29 8:06 ` Guest section DW
2002-03-29 15:45 ` Bill Davidsen
2002-03-29 0:42 ` Bill Davidsen
2002-03-28 22:45 ` Brian Gerst
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=20020329051420.GO21133@turbolinux.com \
--to=adilger@clusterfs.com \
--cc=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.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