[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] turning the root volume into a snapshot stalls (ioctl hangs)


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
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 #1 SMP PREEMPT 2011-07-21 02:17:24 +0200 
x86_64 x86_64 x86_64 GNU/Linux

Best regards,

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

Attachment: signature.asc
Description: This is a digitally signed message part.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]