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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 5 Jun 2018 01:08:54 -0400
From:   "Theodore Y. Ts'o" <>
To:     Maarten van Malland <>
Subject: Re: Problem with external journal and LVM snapshots

On Mon, Jun 04, 2018 at 04:20:45PM +0200, Maarten van Malland wrote:
> Thanks a lot for your very elaborate and informative reply :). You
> were spot-on with everything actually (including the initrd script
> that I made) and the extra information helped me to understand what
> really is going on here. I've tried your suggestion with the debugfs
> command instead of using tune2fs and that worked beautifully. I hope
> that this info will help others as well, as I couldn't find anything
> on google about this. Thanks again.

I am thinking about ways in which "tune2fs -O ^has_journal" could make
the right thing happen, perhaps with warnings.  Some way that it could
determine that it was operating on a snapshot, for example.  Or some
kind of post-snapshot, per-file system hook added to LVM2 to change
the file system UUID.  Or at the very least, tune2fs checking to see
if there are other file systems with the same UUID.

Similarly, maybe the blkid library should be taught to check to
understand block snapshot topology, and to use the "original" file
system as being what's more likely to be wanted if someone is trying
to look up a file system by UUID.

The debugfs script I gave you is a workaround, but it is definitely
still a workaround.  The problem is a real solution is tricky....

      		     	 	      - Ted

Powered by blists - more mailing lists