All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Edward Siefker" <hatta00@fastmail.fm>
To: linux-lvm@redhat.com
Subject: [linux-lvm] /dev/dm-* or /dev/mapper/*
Date: Sun, 16 Aug 2009 17:08:53 -0700	[thread overview]
Message-ID: <1250467733.18434.1330126635@webmail.messagingengine.com> (raw)

I originally set up raid-luks-lvm on this machine with debian's
installer tool, now I am trying to add another encrypted raid1 device to
the existing volume group.  I already have the raid device set up and
encrypted, that's no problem.  Now the linux gazette
(http://linuxgazette.net/140/pfeiffer.html) tells me I should run
'pvcreate' on the device in /dev/mapper.  However, if I examine my
existing physical volumes with 'pvscan' I get the following:

iblis:/home/hatta# pvscan
  PV /dev/dm-0   VG iblis-volumes   lvm2 [931.32 GB / 0    free]
  Total: 1 [931.32 GB] / in use: 1 [931.32 GB] / in no VG: 0 [0   ]

Apparently I am using /dev/dm-0 instead of /dev/mapper/md1_crypt. I
wondered if these were maybe two names for the same thing, so I checked
ls:

iblis:/home/hatta# ls -ld /dev/dm-0 /dev/mapper/md1_crypt
brw-rw---- 1 root disk 253, 0 2009-08-16 12:02 /dev/dm-0
brw-rw---- 1 root disk 253, 0 2009-08-16 12:02 /dev/mapper/md1_crypt

Same major and minor number, if that means anything.  Next I ran
'dmcrypt info' on each:

iblis:/home/hatta# dmsetup info /dev/dm-0
Device /dev/dm-0 not found
Command failed
iblis:/home/hatta# dmsetup info /dev/mapper/md1_crypt 
Name:              md1_crypt
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        7
Event number:      0
Major, minor:      253, 0
Number of targets: 1


It works on one, and not the other.  So they're not the same thing.  My
new device 'md2_crypt' corresponds to /dev/dm-8, if I am to trust the
major/minor numbers. Should I run pvcreate on /dev/dm-8 or
/dev/mapper/md2_crypt?

And this is a somewhat broader question.  If I have two encrypted
volumes like this in the same volume group, and I have a partition that
spans both physical volumes, what happens when one of those volumes is
not yet unlocked?  There is a short time during bootup that md1_crypt is
unlocked and md2_crypt is not yet unlocked. The boot scripts are
definitely doing something with my logical volumes in that period, since
I can use a keyfile in /root (which is in a logical volume on md1_crypt)
to unlock md2_crypt.  

This seems dangerous to me, what would happen if I added md2_crypt to
that volume group, and extended that filesystem over both physical
volumes?  Is it possible for my keyfile in /root to end up on md2_crypt
and be inaccessible?  Suppose I had trouble entering my passphrase 3
times and cryptsetup gave up. What would happen then?  Would my system
try to mount a logical volume that only half exists?  Could that corrupt
the filesystem?
-- 
  
  hatta00@fastmail.fm

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

             reply	other threads:[~2009-08-17  0:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-17  0:08 Edward Siefker [this message]
2009-08-17  1:30 ` [linux-lvm] /dev/dm-* or /dev/mapper/* Ron Johnson
2009-08-17  8:48 ` Peter Rajnoha
2009-08-17  9:01 ` Peter Rajnoha

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=1250467733.18434.1330126635@webmail.messagingengine.com \
    --to=hatta00@fastmail.fm \
    --cc=linux-lvm@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.