linux-ext4 - Re: [PATCH] ext3: allow specifying external journal by pathname mount option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 31 Jul 2013 13:28:24 -0400
From:	Bill McGonigle <bill@...computing.com>
To:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext3: allow specifying external journal by pathname mount
 option

> 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

-- 
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.855.SW.LIBRE
Email, IM, VOIP: bill@...computing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html