From: Kevin Corry <kevcorry@us.ibm.com>
To: dm-devel@redhat.com
Subject: Re: Strange data corruption with RW snapshots
Date: Wed, 5 Oct 2005 10:49:30 -0500 [thread overview]
Message-ID: <200510051049.31055.kevcorry@us.ibm.com> (raw)
In-Reply-To: <20051001112009.GC24685@debian>
Hi Eduard,
On Sat October 1 2005 6:20 am, Eduard Bloch wrote:
> I am trying to create a modified KNOPPIX using devmapper RW snapshots
> instead of its unionfs solution. The problem is: I get corrupted data
> and cannot see where it comes from. The relevant part of setup code
> is attached below. The resulting snapshot volume looks ok at the first
> glance (dmsetup status) and can be mounted (ext2), the directory tree is
> displayed but it returns corruped data on most files. I cannot see the
> problem, a simulation with the same setup method in another environment
> (kernel 2.6.13) did work as expected. Also Ubuntu uses that method for
> their Live CD and there it works as well.
>
> I looked for a good and up-to-date documentation of the snapshot target
> but could not find anything. I hope someone can give me a clue, I cannot
> see how I could solve the problem now.
>
> # state: KNOPDEV is /dev/cloop, readonly block device and mounted on
> # /KNOPPIX, DMSETUP is a static. linked version from devmapper-1.01.04,
> # kernel is .2.6.12 (.4 or so)
> COW_NAME=COW
> CHUNK_SIZE=8
> SNAPSHOT_NAME=knop_rw
> VOL_SIZE=$(blockdev --getsize $KNOPDEV)
>
> # create space for the cow data and assign it to a free loop device COWDEV
> echo | dd bs=1 of=/ramdisk/$COW_NAME seek=`expr 512 \* $VOL_SIZE` count=1 \
> 2>/dev/null
> for x in /dev/loop* ; do
> if losetup $x >/dev/null 2>&1 ; then
> continue
> else
> COWDEV=$x
> break
> fi
> done
> losetup $COWDEV /ramdisk/$COW_NAME
>
> umount /KNOPPIX
> # critical part, no /KNOPPIX/* system tools for now
> $DMSETUP mknodes
> echo "0 $VOL_SIZE linear /dev/cloop 0" | $DMSETUP create knop_ro
If /dev/cloop is read-only (and apparently unmounted anyway), you shouldn't
need to create the knop_ro device. You can just use /dev/cloop directly.
> # this was expected to be a workaround, mapping the loop device to a
> # devmapper volume. It did also fail when using pure $COWDEV
> echo "0 $VOL_SIZE linear $COWDEV 0" | $DMSETUP create cow
This also should not be necessary. What kind of failure do you get if you use
$COWDEV directly?
> echo "0 $VOL_SIZE snapshot /dev/mapper/knop_ro /dev/mapper/cow p \
> $CHUNK_SIZE" | $DMSETUP create $SNAPSHOT_NAME
Based on what I mentioned above, this could be:
echo "0 $VOL_SIZE snapshot /dev/cloop $COWDEV p $CHUNK_SIZE" | \
$DMSETUP create $SNAPSHOT_NAME
> $DMSETUP mknodes $SNAPSHOT_NAME
>
> #remount
> /static/mount /dev/mapper/$SNAPSHOT_NAME /KNOPPIX
> # we are back, rewritable
> bash
> # And this bash command running on /KNOPPIX already fails with obscure
> # errors.
I just ran a similar test (on a 2.6.12 kernel):
# Create loop devices
dd if=/dev/zero of=loop_file0 bs=1M count=1 seek=1024
dd if=/dev/zero of=loop_file1 bs=1M count=1 seek=1024
losetup /dev/loop0 loop_file0
losetup /dev/loop1 loop_file1
# Create filesystem on first loop device and copy some data to it.
mkfs.ext3 /dev/loop0
mount /dev/loop0 /mnt/loop0/
cp -a /usr/src/linux-2.6.12 /mnt/loop0/
umount /mnt/loop0
# Create the snapshot.
echo "0 `blockdev --getsize /dev/loop0` snapshot /dev/loop0 /dev/loop1 p 8" \
| dmsetup create loop_snap
# Mount the snapshot. Compare data and modify data.
mount /dev/mapper/loop_snap /mnt/loop_snap
cd /mnt/loop_snap
diff -Naur --brief linux-2.6.12 /usr/src/linux-2.6.12
cp -a /usr/src/linux-2.6.11 .
rm -rf linux-2.6.12
diff -Naur --brief linux-2.6.11 /usr/src/linux-2.6.11
cd /
# Unmount the snapshot. Deactivate and reactivate the snapshot. Mount again
# and compare and modify data again.
umount /mnt/loop_snap
dmsetup remove loop_snap
echo "0 `blockdev --getsize /dev/loop0` snapshot /dev/loop0 /dev/loop1 p 8" \
| dmsetup create loop_snap
mount /dev/mapper/loop_snap /mnt/loop_snap
cd /mnt/loop_snap
diff -Naur --brief linux-2.6.11 /usr/src/linux-2.6.11
rm -rf linux-2.6.11
I have not seen any kind of errors at all. What specific errors are you
getting? Anything in the kernel log? Can you test again without the extra
dm-linear devices?
--
Kevin Corry
kevcorry@us.ibm.com
http://www.ibm.com/linux/
http://evms.sourceforge.net/
next prev parent reply other threads:[~2005-10-05 15:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-01 11:20 Strange data corruption with RW snapshots Eduard Bloch
2005-10-05 15:49 ` Kevin Corry [this message]
2005-10-05 16:16 ` Eduard Bloch
2005-10-06 16:59 ` Eduard Bloch
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=200510051049.31055.kevcorry@us.ibm.com \
--to=kevcorry@us.ibm.com \
--cc=dm-devel@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.