Skip to contentSkip to conversation

ext3: allow specifying external journal by pathname mount option

PATCH Bill McGonigle 2 participants 4 messages Jul 31, 2013 – Aug 1, 2013

lore
Share & tools
lore
#0 lore raw
Quoted 5 lines

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. 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

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.

-Bill

Signature · 7 lines
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: [email protected]
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
#1 lore raw
Quoted 22 lines · Bill McGonigle
Quoted 5 lines

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.

Quoted 3 lines

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? ;)

Quoted 7 lines

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.

Quoted 7 lines

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

Quoted 2 lines

-Bill

#2 lore raw
Quoted 1 line · Eric Sandeen

well, kernelspace can't use libblkid.

ah, right. But userspace could, and with your patch, basically do the same thing and mount using the UUID number stored in the superblock using the 'by-uuid' path. Sweet.

Quoted 1 line

I'll send the ext4 version in a minute if you want to try it.

that would be super - I'd be happy to test it soon.

-Bill

Signature · 7 lines
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: [email protected]
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
#3 lore raw
Quoted 6 lines · Bill McGonigle
Quoted 1 line · Eric Sandeen

well, kernelspace can't use libblkid.

ah, right. But userspace could, and with your patch, basically do the same thing and mount using the UUID number stored in the superblock using the 'by-uuid' path. Sweet.

yeah. Right now mount can't parse i.e. "journal_path=UUID=$UUID" type options as it can do for the device specification, but if the /dev/disk/by-uuid paths are set up by the time you mount the fs, that works too.

Quoted 3 lines
Quoted 1 line

I'll send the ext4 version in a minute if you want to try it.

that would be super - I'd be happy to test it soon.

K, it's on the list now. :)

-Eric

Quoted 2 lines

-Bill