From: Stuart D Gathman <stuart@bmsi.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] COW store
Date: Mon, 19 Jul 2010 09:22:30 -0400 [thread overview]
Message-ID: <4C445196.7030203@bmsi.com> (raw)
In-Reply-To: <846462.8576.qm@web137317.mail.in.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]
On 07/19/2010 07:14 AM, andiket a wrote:
> Is it possible to specify a different device or to be specific a
> different VG than original VG to create a cow store for snapshot.
>
> If I have a an LV in VG1 then I don't snapshot to create cow store
> (snapshot LV) on same VG but to use VG2.
>
Short answer: no
Long answer: support for this would defeat the purpose of volume
groups. VGs have independent metadata so that you can remove them
independently, move between system, and so on. If a misguided soul were
to implement your feature, then the two volume groups would have to be
"locked together" so that removing one or the other would invalidate the
snapshot. For similar reasons, you cannot hardlink files between unix
filesystems.
If you are using volume groups for the naming only, try using a
separator in your LV names. (LVM lawyers - what are legal chars to
use?) For instance, I know '_' is safe, so for example instead of
vgabc/lv1 and vgdef/lv2, where you are willing to "entangle" vgabc and
vgdef because they are always online together, just make a single vgroot and
use vgroot/abc_lv1 vgroot/def_lv2.
BTW, A feature that would make more sense would be hierarchical
namespace for LVs within a VG, i.e. subdirs within the /dev/vg*
directory. Very low priority, and tricky, but would be handy for naming
purposes.
[-- Attachment #2: Type: text/html, Size: 2082 bytes --]
next prev parent reply other threads:[~2010-07-19 13:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-19 11:14 [linux-lvm] COW store andiket a
2010-07-19 13:22 ` Stuart D Gathman [this message]
2010-07-19 14:58 ` ejt
2010-07-19 19:03 ` andiket a
2010-07-19 15:45 ` Greg Freemyer
2010-07-19 19:06 ` andiket a
2010-07-19 21:12 ` Greg Freemyer
2010-07-20 6:29 ` andiket a
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=4C445196.7030203@bmsi.com \
--to=stuart@bmsi.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).