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-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 16 Jul 2012 19:30:10 +0930
From:	Kevin Shanahan <kmshanah@...enchant.net>
To:	Andreas Dilger <aedilger@...il.com>
Cc:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: Ext4 external journal UUID mismatch?

On Sun, Jul 15, 2012 at 10:32:01PM -0600, Andreas Dilger wrote:
> On 2012-07-15, at 20:56, Kevin Shanahan <kmshanah@...enchant.net> wrote:
> 
> > On Mon, Jul 16, 2012 at 09:10:58AM +0930, Kevin Shanahan wrote:
> >> I have created some filesystems with external journals, and after
> >> reboot (clean shutdown) these will not mount anymore. I see in dmesg:
> >> 
> >>  [42214.365496] EXT4-fs (dm-10): journal UUID does not match
> >> 
> >> However, the UUIDs look fine when viewed with dumpe2fs:
> >> 
> > Here is what e2fsck said about it.
> > 
> > # e2fsck -p -j /dev/ssdvg/jnl-kvmhost0 /dev/it8/nfs-kvmhost0
> > /dev/it8/nfs-kvmhost0: Superblock hint for external superblock should be 0xfd0d.  FIXED.
> > /dev/it8/nfs-kvmhost0: clean, 43229/983040 files, 303609/3932160 blocks
> > 
> > I guess that is the "Journal Device" field? Mount worked fine after
> > that and the data looks okay.
> > 
> > Any idea how this might have happened across all three fs with
> > external journals?
> 
> Because LVM changed the block device numbers after the reboot, and
> the device number used previously for the external journal was
> different.
> 
> The lookup of the journal by UUID (instead of relying on the "device
> hint" in the superblock) _should_ be handled by mount, but I don't
> recall if we ever got a mount.ext4 to handle this or not. It would
> also be possible for the "fast e2fsck" check to verify the journal
> UUID before mounting the filesystem, but again I'm not sure if this
> is done yet, and I can't check right now.

Ok, thanks. For now I can ask LVM to make the major/minor number
persistent.

Assuming it's not already done, do you think adding the UUID lookup
would be a reasonable project for a newbie or is it likely to be a bit
complicated?

I'm assuming support is not there, at least for the versions in Arch:

$ pacman -Q e2fsprogs util-linux
e2fsprogs 1.42.4-1
util-linux 2.21.2-5

Cheers,
Kevin.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ