[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180605050854.GB6651@thunk.org>
Date: Tue, 5 Jun 2018 01:08:54 -0400
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Maarten van Malland <maartenvanmalland@...il.com>
Cc: linux-ext4@...r.kernel.org
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