FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 11-08-2011, 12:21 PM
Mike Snitzer
 
Default turning the root volume into a snapshot stalls (ioctl hangs)

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:
1 mem
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

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Tue Nov 8 15:30:02 2011
Return-path: <arch-general-bounces@archlinux.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Tue, 08 Nov 2011 15:29:37 +0200
Received: from gerolde.archlinux.org ([66.211.214.132]:40444 helo=archlinux.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <arch-general-bounces@archlinux.org>)
id 1RNlk9-0003j2-2E
for tom@linux-archive.org; Tue, 08 Nov 2011 15:29:37 +0200
Received: from gudrun.archlinux.org (gudrun.archlinux.org [66.211.214.131])
by archlinux.org (Postfix) with ESMTP id 5B01E90204;
Tue, 8 Nov 2011 08:29:12 -0500 (EST)
Received: from archlinux.org (gerolde.archlinux.org [66.211.214.132])
by gudrun.archlinux.org (Postfix) with ESMTP id 9587C84CF9
for <arch-general@archlinux.org>; Tue, 8 Nov 2011 08:29:10 -0500 (EST)
Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.214.44 is authorized
to use 'bo.bjornsen@gmail.com' in 'mfrom' identity (mechanism
'ip4:209.85.128.0/17' matched)) receiver=gerolde.archlinux.org;
identity=mailfrom; envelope-from="bo.bjornsen@gmail.com";
helo=mail-bw0-f44.google.com; client-ip=209.85.214.44
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com
[209.85.214.44])
by archlinux.org (Postfix) with ESMTPS id 276FB90203;
Tue, 8 Nov 2011 08:29:09 -0500 (EST)
Received: by bkbzv15 with SMTP id zv15so368609bkb.3
for <multiple recipients>; Tue, 08 Nov 2011 05:29:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=message-id:date:from:user-agent:mime-version:to:cc:subject
:x-enigmail-version:x-enigmail-draft-status:content-type
:content-transfer-encoding;
bh=+Xl3MZ6hTf7vbh+CeUJZG6xX1aWTtQsjhPFvP52plrU=;
b=noDgbgidwXeZDUgxta5zJkONe6SCHsp+pZJVXYA0JVBNbPP/8wOtgif5WHH1DcuGem
1MpK0QMRvBCHUBI9ExtYlDLh7kB1Koz9zjWxMGq01eNfwj8oNw Km/u6rO0hEXenPNfF7
KC+7vdhftmbUPj8wPR+29fkBmVn1Rmj9atvWw=
Received: by 10.204.132.71 with SMTP id a7mr22857523bkt.93.1320758972666;
Tue, 08 Nov 2011 05:29:32 -0800 (PST)
Received: from [192.168.201.177] (16.82.213.193.static.cust.telenor.com.
[193.213.82.16])
by mx.google.com with ESMTPS id z7sm1587950bka.1.2011.11.08.05.29.30
(version=SSLv3 cipher=OTHER); Tue, 08 Nov 2011 05:29:31 -0800 (PST)
Message-ID: <4EB92E8E.7050707@gmail.com>
Date: Tue, 08 Nov 2011 14:28:46 +0100
From: =?ISO-8859-1?Q?Bj=F8rn_=D8ivind_Bj=F8rnsen?=
<bo.bjornsen@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1
MIME-Version: 1.0
To: arch-general@archlinux.org
X-Enigmail-Version: 1.3.2
X-Enigmail-Draft-Status: 513
Content-Type: text/plain; charset=ISO-8859-1
Cc: andrea@archlinux.org
Subject: [arch-general] Compiling qt-4.8rc1 from [testing] fails
X-BeenThere: arch-general@archlinux.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: General Discussion about Arch Linux <arch-general@archlinux.org>
List-Id: General Discussion about Arch Linux <arch-general.archlinux.org>
List-Unsubscribe: <http://mailman.archlinux.org/mailman/options/arch-general>,
<mailto:arch-general-request@archlinux.org?subject=unsubscribe>
List-Archive: <http://mailman.archlinux.org/pipermail/arch-general>
List-Post: <mailto:arch-general@archlinux.org>
List-Help: <mailto:arch-general-request@archlinux.org?subject=help>
List-Subscribe: <http://mailman.archlinux.org/mailman/listinfo/arch-general>,
<mailto:arch-general-request@archlinux.org?subject=subscribe>
Errors-To: arch-general-bounces@archlinux.org
Sender: arch-general-bounces@archlinux.org
Content-Transfer-Encoding: quoted-printable


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello list,

The latest qt-package in testing broke one of the applications I am
working on at the moment.
It compiles fine, but crashes during runtime, so I tried to compile qt
with debug symbols. I did the same thing as I usually do when I have to
poke qt-internals - added '!strip' to the options in the PKGBUILD and
tried to compile the package again. The PKGBUILD and friends were
obtained from abs. However, the compilation fails in tools/assistant,
with the following errors:

make[4]: Entering directory
`/home/bo/pakker/qt-4.8rc1/src/qt-everywhere-opensource-src-4.8.0/tools/a=
ssistant/tools/assistant'
compiling helpviewer_qwv.cpp
helpviewer_qwv.cpp:168:1: error: expected class-name before ?{? token
helpviewer_qwv.cpp:173:13: error: ?QWebPage? does not name a type
helpviewer_qwv.cpp:174:32: error: ?WebAction? has not been declared
helpviewer_qwv.cpp:176:42: error: ?QWebFrame? has not been declared
helpviewer_qwv.cpp:177:41: error: ?NavigationType? has not been declared
helpviewer_qwv.cpp: In constructor ?HelpPage::HelpPage(QObject*)?:
helpviewer_qwv.cpp:189:7: error: class ?HelpPage? does not have any
field named ?QWebPage?
helpviewer_qwv.cpp: At global scope:
helpviewer_qwv.cpp:197:1: error: ?QWebPage? does not name a type
helpviewer_qwv.cpp:207:30: error: variable or field ?triggerAction?
declared void
helpviewer_qwv.cpp:207:30: error: ?WebAction? was not declared in this sc=
ope
helpviewer_qwv.cpp:207:48: error: expected primary-expression before ?boo=
l?
make[4]: *** [.obj/release-shared/helpviewer_qwv.o] Error 1
make[4]: Leaving directory
`/home/bo/pakker/qt-4.8rc1/src/qt-everywhere-opensource-src-4.8.0/tools/a=
ssistant/tools/assistant'
make[3]: *** [sub-assistant-make_default-ordered] Error 2
make[3]: Leaving directory
`/home/bo/pakker/qt-4.8rc1/src/qt-everywhere-opensource-src-4.8.0/tools/a=
ssistant/tools'
make[2]: *** [sub-tools-make_default-ordered] Error 2
make[2]: Leaving directory
`/home/bo/pakker/qt-4.8rc1/src/qt-everywhere-opensource-src-4.8.0/tools/a=
ssistant'
make[1]: *** [sub-assistant-make_default-ordered] Error 2
make[1]: Leaving directory
`/home/bo/pakker/qt-4.8rc1/src/qt-everywhere-opensource-src-4.8.0/tools'
make: *** [sub-tools-make_default-ordered] Error 2
=3D=3D> ERROR: A failure occurred in build().

I noticed that qtwebkit was split out of this package. Have I missed
some other piece of vital information which allows me to compile this,
and does anyone else see this? I could reproduce this on two x86_64
machines here, -Syu'ed as of today.
I would be thankful for any tips

Regards,
Bj=F8rn =D8ivind
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOuS6BAAoJEAPvNxjF/T/2kR0P/2ycR9+3LlYaJOnosVJnSuRH
9tN9eT/WZY1cHEyxQAJuux2GQ0L2oECYc6BumPPQ6EJ7WLgKe9jgwoYTJ ZN5QSxC
Mp5noNmiyqInWp75p53kzyAg30XKYKWqRZbaV+mcXHra3aZ4yd C1rxEEG5FDVQx2
GauKhGqaZ5RKdtO4b/6rCQtAjGSv4l7QvLErFkRAYSqsaK7XKiDGatPOAkalxw6X
/T0dhyKDP4r6V8DHUOqekbrNX9Oupso8GPHRMhTqO8jSuOtUD/ie0D6lkepArG+v
HXDYsxVF+Fepr1CLfAD2xM3p8JrKqdiPjbXdnqmcSGiWMzkSon lWl66Y4Lcnrs5c
Uqa8XFVcLYvJ9MOgV3VBdpJijGIzvrYWKI8FunxU1EeOPNmPYi g+zg85ArP8OTiT
ZtNgM4jTrQGGQCMK5tjY2Ji8YhVL5b0nv4yroV9jQ8q9yhY4pO giEqxdYAPtw0QY
bFsSrlQH8QQD/SNd98xIl3qzNeq7Nq5Dc/OwP9I/scA+Je2DM9P2oX0X++mVvkiL
fN7Qtst1j8u2TyXDfPf2cSCw+kPIZLct++0+5UmC92p1UPcddm VTg4JZl68EZPNe
3u7yjJ9lfHZjktb5P/fyaTfxiZ4gshuQL2fITwR5MFjZ/o6TB0TFCSfBF9+HlZZk
aa9dFnmP/REmH8oQUdEO
=3DbFqE
-----END PGP SIGNATURE-----
 
Old 11-08-2011, 05:29 PM
Hauke Laging
 
Default turning the root volume into a snapshot stalls (ioctl hangs)

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
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 11:34 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org