From: Eric Sandeen <sandeen@redhat.com>
To: Bill McGonigle <bill@bfccomputing.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext3: allow specifying external journal by pathname mount option
Date: Wed, 31 Jul 2013 14:45:40 -0500 [thread overview]
Message-ID: <51F96964.4000608@redhat.com> (raw)
In-Reply-To: <51F94938.1040303@bfccomputing.com>
On 7/31/13 12:28 PM, Bill McGonigle wrote:
>
>> Adding a mount option, "-o journal_path=/dev/$DEVICE" would help,
>> since then we can do i.e.
>>
>> # mount -o journal_path=/dev/disk/by-label/$JOURNAL_LABEL /mnt
>
> I came here with a related problem, and I wonder if it would be a
> more general solution to this one too.
>
> I've got a machine with root on ext4 on LUKS on md, and while I was
> first planning to use flashcache or dm-cache underneath it (for SSD
> acceleration) I saw benchmarks that convinced me that an external
> journal on ext4 was the better option.
>
> It's getting it mounted at boot time that's the trick.
>
> I saw that tune2fs supports '-J device=UUID=foo-bar-baz', so I setup
> a LUKS volume on the SSD, formatted it, passed it in, and it sets up
> the journal fine when I'm booted from external media, but when I
> reboot under the OS (3.10 in Fedora 19 in this case) it fails to
> mount because the device number has changed.
>
> I see the proper UUID listed in 'tune2fs -l' - the "Journal UUID" is
> right, but "Journal device" is no longer correct, so boot fails until
> I remove the journal again.
Neat eh? ;)
> I think with LUKS, I'm never guaranteed
> to get a consistent device ID between boots, so the kernel command
> line options don't help either.
>
> So, I was thinking, that if the ext code did: 1) try stored journal
> device ID 2) on fail, look up the UUID via libblkid 3) perhaps update
> the stored device ID
well, kernelspace can't use libblkid.
> it would solve my problem. I wonder if it would be a more robust
> solution to the problem posed here as well (having the filesystem
> contain its own references is better IMHO). My one handy system that
> has an ext3 volume (still on Fedora 16, e2fsprogs-1.41) does not show
> a Journal UUID flag via 'tune2fs -l', but I'm unaware of whether the
> flag is unavailable/missing/unsupported there or if it could be
> added.
I think my patch will solve your problems as it is, just add the new
mount option to fstab, remake your init$WHATEVER, and off you'll go.
I'll send the ext4 version in a minute if you want to try it.
-Eric
> -Bill
>
next prev parent reply other threads:[~2013-07-31 19:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-31 17:28 [PATCH] ext3: allow specifying external journal by pathname mount option Bill McGonigle
2013-07-31 19:45 ` Eric Sandeen [this message]
2013-08-01 6:51 ` Bill McGonigle
2013-08-01 17:23 ` Eric Sandeen
-- strict thread matches above, loose matches on Subject: below --
2013-07-30 22:26 Eric Sandeen
2013-07-31 14:05 ` Jan Kara
2013-07-31 14:16 ` Eric Sandeen
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=51F96964.4000608@redhat.com \
--to=sandeen@redhat.com \
--cc=bill@bfccomputing.com \
--cc=linux-ext4@vger.kernel.org \
/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.