From: Gordon Messmer <gordon.messmer@gmail.com>
To: linux-ext4@vger.kernel.org
Subject: kernel panic using external journal and snapshots
Date: Mon, 11 Nov 2013 20:03:47 -0800 [thread overview]
Message-ID: <5281A8A3.80604@gmail.com> (raw)
I'm developing backup infrastructure for Linux using snapshots. One of
the supported configurations is EXT4 on LVM, but I think I've come
across a bug.
I'm currently testing on CentOS 6, with kernel 2.6.32-358.6.1.el6.x86_64
If I create a snapshot of a filesystem with an external journal, and
mount that snapshot while the original filesystem is mounted, the system
will usually kernel panic. If it does not panic, then the kernel will
later refuse to mount it because "External journal has more than one
user." So, the first bug seems to be that ext4 doesn't check the
external journal before mounting the new snapshot to ensure that the
journal is not in use. Expected behavior is that the kernel would
refuse to mount a filesystem whose journal already has a "user" in order
to prevent a kernel panic.
If that were the extent of the problem, I probably wouldn't bother
reporting the issue. However, the kernel will STILL panic if I use
tune2fs to remove the journal, and even if I use tune2fs to create a new
internal journal. The second bug, then, seems to be that once an ext4
filesystem has an external journal, that journal will continue to be
used after it has been removed, and even if it is replaced with an
internal journal.
The following commands were used to test the problem. These are
basically the commands run by the "snapshot" application. It sets a
minimum snapshot size of 10% of the volume size, then reads the size of
the volume and the size remaining in the volume group. It creates a
uuid for the snapshot name, then creates the new snapshot. I use
tune2fs first to verify that there is a journal device recorded, then
remove the journal. Afterward, I read the value again and find no
external journal recorded. When the filesystem is mounted, the kernel
will usually panic.
Is this a known bug? I haven't yet built a newer system to test the
effects on the current kernel version.
min_size=10
lvsize=$(lvs --noheadings --units m --nosuffix -o lv_size
"VolGroup/lv_var" | cut -f1 -d.)
vgfree=$(vgs --noheadings --units m --nosuffix -o vg_free
"/dev/VolGroup" | cut -f1 -d.)
test "$vgfree" -gt $(( $lvsize * $min_size / 100 )) || echo Not enough
free space on "/dev/VolGroup" for snapshot
uuid=$(uuidgen)
lvcreate -s -n "lv_var-snap-${uuid}" -L "$(( $lvsize * $min_size / 100
))"m "VolGroup/lv_var"
Rounding up size to full physical extent 128.00 MiB
Logical volume
"lv_var-snap-66c41691-21c0-4db2-8af2-09a13d87a881" created
tune2fs -l "/dev/VolGroup/lv_var-snap-${uuid}" | grep "^Journal device:"
Journal device: 0xfd04
tune2fs -O ^has_journal "/dev/VolGroup/lv_var-snap-${uuid}"
tune2fs 1.41.12 (17-May-2010)
Journal removed
tune2fs -l "/dev/VolGroup/lv_var-snap-${uuid}" | grep "^Journal device:"
mount "/dev/VolGroup/lv_var-snap-${uuid}" /mnt
* kernel panic *
https://bitbucket.org/gordonmessmer/dragonsdawn-snapshot
next reply other threads:[~2013-11-12 4:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 4:03 Gordon Messmer [this message]
2013-11-22 7:11 ` kernel panic using external journal and snapshots Zheng Liu
2013-11-23 20:30 ` Gordon Messmer
2013-11-25 3:32 ` Zheng Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5281A8A3.80604@gmail.com \
--to=gordon.messmer@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).