turning the root volume into a snapshot stalls (ioctl hangs)

turning the root volume into a snapshot stalls (ioctl hangs)

[Hauke Laging]

[-- Attachment #1.1: Type: Text/Plain, Size: 2612 bytes --]

Hello,

for energy saving purposes I try to buffer disk accesses in RAM by making the 
mounted (LVM) volume a snapshot and putting the COW device on tmpfs (loop 
device over a sparse file) so that I can flush the changes later by making the 
volume a snapshot-merge target. Note: I am NOT trying to make a snapshot of 
the root volume! (This has obviously been done sucessfully by others.)

This works for a data volume but the system hangs when trying this with the 
root volume. The interesting point: The problem seems not to be caused by an 
access to the root filesystem.

I have created a chroot environment in a tmpfs volume (and sucessfully done 
this with a data volume from there). The relevant part of the script (located 
in the chroot environment, of course) is:

dmsetup suspend "$cryptodevice_name" || exit 1
dmsetup load "$cryptodevice_name" --table "0 ${origin_block_count} \
     snapshot-merge ${origin_major_minor} ${cow_major_minor} P 8" || exit 1
dmsetup resume "$cryptodevice_name" || exit 1

The hanging occurs during the "dmsetup load". I hat a look at it by strace. 
This is what happens with the data volume:

[...]
stat("/dev/mapper/control", {st_mode=S_IFCHR|0600, st_rdev=makedev(10, 236), 
...}) = 0
open("/dev/mapper/control", O_RDWR) = 3
open("/proc/devices", O_RDONLY)   = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f855bec6000
read(4, "Character devices:\n  1 mem\n  4 /"..., 1024) = 490
close(4)                          = 0
munmap(0x7f855bec6000, 4096)      = 0
ioctl(3, DM_VERSION, 0x6162a0)    = 0
ioctl(3, DM_TABLE_LOAD, 0x6161f0) = 0
close(3)                          = 0
exit_group(0)                     = ?
[...]

The same call for the root volume leads to
[...]
ioctl(3, DM_TABLE_LOAD, 0x6161f0) =
(I am not sure about the 0x6161f0)
The exit code never appears. I do not know whether this is a problem of the 
ioctl or one of strace. But as the volume has already been suspended at that 
time I do not see any reason why strace should be affected. The system is not 
completely dead but no useful actitivy is possible any more.

Issuing a suspend and a resume immediately afterwards (without the load) does 
not kill the system. So the problem seems to be about the dmsetup load.

This is openSUSE 11.4.
start cmd:> uname -a
Linux inno 2.6.37.6-0.7-desktop #1 SMP PREEMPT 2011-07-21 02:17:24 +0200 
x86_64 x86_64 x86_64 GNU/Linux


Best regards,

Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: turning the root volume into a snapshot stalls (ioctl hangs)

[Mike Snitzer]

On Tue, Nov 08 2011 at  6:57am -0500,
Hauke Laging <mailinglisten@hauke-laging.de> wrote:

> Hello,
> 
> for energy saving purposes I try to buffer disk accesses in RAM by making the 
> mounted (LVM) volume a snapshot and putting the COW device on tmpfs (loop 
> device over a sparse file) so that I can flush the changes later by making the 
> volume a snapshot-merge target. Note: I am NOT trying to make a snapshot of 
> the root volume! (This has obviously been done sucessfully by others.)
> 
> This works for a data volume but the system hangs when trying this with the 
> root volume. The interesting point: The problem seems not to be caused by an 
> access to the root filesystem.
> 
> I have created a chroot environment in a tmpfs volume (and sucessfully done 
> this with a data volume from there). The relevant part of the script (located 
> in the chroot environment, of course) is:
> 
> dmsetup suspend "$cryptodevice_name" || exit 1
> dmsetup load "$cryptodevice_name" --table "0 ${origin_block_count} \
>      snapshot-merge ${origin_major_minor} ${cow_major_minor} P 8" || exit 1
> dmsetup resume "$cryptodevice_name" || exit 1
> 
> The hanging occurs during the "dmsetup load". I hat a look at it by strace. 
> This is what happens with the data volume:
> 
> [...]
> stat("/dev/mapper/control", {st_mode=S_IFCHR|0600, st_rdev=makedev(10, 236), 
> ...}) = 0
> open("/dev/mapper/control", O_RDWR) = 3
> open("/proc/devices", O_RDONLY)   = 4
> fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0x7f855bec6000
> read(4, "Character devices:\n  1 mem\n  4 /"..., 1024) = 490
> close(4)                          = 0
> munmap(0x7f855bec6000, 4096)      = 0
> ioctl(3, DM_VERSION, 0x6162a0)    = 0
> ioctl(3, DM_TABLE_LOAD, 0x6161f0) = 0
> close(3)                          = 0
> exit_group(0)                     = ?
> [...]
> 
> The same call for the root volume leads to
> [...]
> ioctl(3, DM_TABLE_LOAD, 0x6161f0) =
> (I am not sure about the 0x6161f0)
> The exit code never appears. I do not know whether this is a problem of the 
> ioctl or one of strace. But as the volume has already been suspended at that 
> time I do not see any reason why strace should be affected. The system is not 
> completely dead but no useful actitivy is possible any more.
> 
> Issuing a suspend and a resume immediately afterwards (without the load) does 
> not kill the system. So the problem seems to be about the dmsetup load.

So you're somehow activating the snapshot to be the root volume.  And
then later trying to merge the tmpfs COW into the origin (obviously
before you reboot otherwise you'd lose the tmpfs).  This isn't going to
work with the current snapshot-merge code given the constraints that
both the origin and snapshot must be closed before merge.

Merging a snapshot into a root volume must occur at first activation
(before it is opened for use by the system).

The lvm tools both document and guard against this, from lvconvert(8):
   Merging a snapshot into an origin that cannot be closed, for
   example a root filesystem, is deferred until the next time the origin
   volume is activated.

Mike

Re: turning the root volume into a snapshot stalls (ioctl hangs)

[Hauke Laging]

[-- Attachment #1.1: Type: Text/Plain, Size: 1540 bytes --]

Am Dienstag, 8. November 2011, 14:21:21 schrieb Mike Snitzer:
> So you're somehow activating the snapshot to be the root volume.  And
> then later trying to merge the tmpfs COW into the origin (obviously
> before you reboot otherwise you'd lose the tmpfs).  This isn't going to
> work with the current snapshot-merge code given the constraints that
> both the origin and snapshot must be closed before merge.

Yes but not even the snapshot part works (I copied the code in the first mail 
from the wrong part of the script; it should have been "snaphot" instead of 
"snapshot-merge".


> The lvm tools both document and guard against this, from lvconvert(8):

OK, I don't use lvconvert thus I had not read that.


>    Merging a snapshot into an origin that cannot be closed, for
>    example a root filesystem, is deferred until the next time the origin
>    volume is activated.

I am curious: Is there a technical explanation of this problem? I do not 
understand what "close" is supposed to mean in this context and how the root 
volume is different from the home volume (with users logged in).

Could this restriction be avoided by using another dm layer? I have an LV 
linux2/rootfs. If I create a new dm device rootfs and have it point to 
/dev/mapper/linux2-rootfs would the restriction apply to both then? It is not 
necessary in this case that the file system gets flushed (and the superblock 
cleaned).


Thanks for your help

Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]