linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: ext4 development <linux-ext4@vger.kernel.org>,
	Leonardo Menezes Vaz <lvaz@redhat.com>
Subject: Re: [PATCH] ext3: allow specifying external journal by pathname mount option
Date: Wed, 31 Jul 2013 09:16:03 -0500	[thread overview]
Message-ID: <51F91C23.7020402@redhat.com> (raw)
In-Reply-To: <20130731140545.GA22930@quack.suse.cz>

On 7/31/13 9:05 AM, Jan Kara wrote:
> On Tue 30-07-13 17:26:24, Eric Sandeen wrote:
>> It's always been a hassle that if an external journal's
>> device number changes, the filesystem won't mount.
>> And since boot-time enumeration can change, device number
>> changes aren't unusual.
>>
>> The current mechanism to update the journal location is by
>> passing in a mount option w/ a new devnum, but that's a hassle;
>> it's a manual approach, fixing things after the fact.
>>
>> 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
>>
>> and it'll mount even if the devnum has changed, as shown here:
>>
>> # losetup /dev/loop0 journalfile
>> # mke2fs -L mylabel-journal -O journal_dev /dev/loop0 
>> # mkfs.ext3 -L mylabel -J device=/dev/loop0 /dev/sdb1
>>
>> Change the journal device number:
>>
>> # losetup -d /dev/loop0
>> # losetup /dev/loop1 journalfile 
>>
>> And today it will fail:
>>
>> # mount /dev/sdb1 /mnt/test
>> mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
>>        missing codepage or helper program, or other error
>>        In some cases useful info is found in syslog - try
>>        dmesg | tail  or so
>>
>> # dmesg | tail -n 1
>> [17343.240702] EXT3-fs (sdb1): error: couldn't read superblock of external journal
>>
>> But with this new mount option, we can specify the new path:
>>
>> # mount -o journal_path=/dev/loop1 /dev/sdb1 /mnt/test
>> #
>>
>> (which does update the encoded device number, incidentally):
>>
>> # umount /dev/sdb1
>> # dumpe2fs -h /dev/sdb1 | grep "Journal device"
>> dumpe2fs 1.41.12 (17-May-2010)
>> Journal device:	          0x0701
>>
>> But best of all we can just always mount by journal-path, and
>> it'll always work:
>>
>> # mount -o journal_path=/dev/disk/by-label/mylabel-journal /dev/sdb1 /mnt/test
>> #
>>
>> So the journal_path option can be specified in fstab, and as long as
>> the disk is available somewhere, and findable by label (or by UUID),
>> we can mount.
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>> ---
>>
>> The patch is a little hacky, doing all the work in option parsing,
>> just to get to a journal devnum like the old option expected, only
>> to later re-decode it when we really want to open it.
>>
>> I could clean it up so that both journal-update mount options
>> find the bdev, rather than ending with an encoded device number,
>> which must then be decoded & re-opened, if that seems better.
>>
>> But this was expedient enough to get the idea out on the list.
>>
>> If we like it, I'll do ext4 as well.
>   Yeah, it looks like a good idea. You could just lookup the path via
> kern_path() and then take the device numbers from the inode so you won't
> have to do the decode-recode dance. That would look like the cleanest option
> to me.
> 
> 								Honza

Ah, thanks for the suggestion, I'll give that a shot.

-Eric

  reply	other threads:[~2013-07-31 14:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-30 22:26 [PATCH] ext3: allow specifying external journal by pathname mount option Eric Sandeen
2013-07-31 14:05 ` Jan Kara
2013-07-31 14:16   ` Eric Sandeen [this message]
2013-07-31 19:33 ` [PATCH V2] " Eric Sandeen
2013-07-31 20:10   ` Jan Kara
  -- strict thread matches above, loose matches on Subject: below --
2013-07-31 17:28 [PATCH] " Bill McGonigle
2013-07-31 19:45 ` Eric Sandeen
2013-08-01  6:51   ` Bill McGonigle
2013-08-01 17:23     ` 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=51F91C23.7020402@redhat.com \
    --to=sandeen@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=lvaz@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).