From: Mike Snitzer <snitzer@redhat.com>
To: "Stuart D. Gathman" <stuart@bmsi.com>
Cc: LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] Snapshots
Date: Fri, 17 Feb 2012 08:56:24 -0500 [thread overview]
Message-ID: <20120217135624.GA3172@redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.00.1202162343130.9285@bmsred.bmsi.com>
On Thu, Feb 16 2012 at 11:46pm -0500,
Stuart D. Gathman <stuart@bmsi.com> wrote:
> Long ago, Nostradamus foresaw that on Feb 16, Mike Snitzer would write:
>
> >>An elegant part of the LVM system is that the device mapper kernel support is
> >>very general, and new data structures can be experimented with entirely in user
> >>code - with a script language even. Metadata for experimental structures does
> >>not have to stored with the main metadata.
> >
> >Please note that the dm-thinp code has metadata in the kernel (on-disk
> >format for btrees, etc) much like a filesystem would have. So there is
> >both kernel and userspace (lvm2) metadata for dm-thinp.
>
> Yes, but isn't this loaded into the kernel via userland tools like
> device-mapper?
The 'thin-pool' and 'thin' DM device tables are loaded from userspace
via DM interfaces.
The kernel metadata isn't loaded from userspace. It is created and/or
changed by certain actions taken from userspace (via DM messages).
> So while a kernel feature would be required for a new
> type of kernel metadata, experimental uses of existing formats can
> be done in userland.
The kernel manages the kernel's metadata. But the LVM metadata that
userspace uses to coordinate and manage the thin devices can be
changed independently.
The thin-provisioning-tools know the kernel's metadata format and can
check it (and in the future repair it).
next prev parent reply other threads:[~2012-02-17 13:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-16 13:25 [linux-lvm] Snapshots Mark Woodward
2012-02-16 13:57 ` Mike Snitzer
2012-02-16 14:05 ` Marco Pizzoli
2012-02-17 15:20 ` Mike Snitzer
2012-02-16 14:42 ` Mark Woodward
2012-02-16 15:18 ` Stuart D. Gathman
2012-02-16 15:54 ` Mike Snitzer
2012-02-17 4:46 ` Stuart D. Gathman
2012-02-17 13:56 ` Mike Snitzer [this message]
2012-02-16 16:51 ` Bryn M. Reeves
2012-02-16 15:43 ` Mike Snitzer
2012-02-16 16:04 ` Mark Woodward
2012-02-16 16:09 ` Mike Snitzer
-- strict thread matches above, loose matches on Subject: below --
2009-09-17 14:24 Jon Hardcastle
2009-09-17 14:37 ` Peter Keller
2009-09-10 23:25 jonr
2009-09-11 9:14 ` Peter Keller
2009-09-11 13:39 ` André Gillibert
2001-10-18 20:35 [linux-lvm] snapshots Robert Dyas
2001-10-18 21:11 ` Andreas Dilger
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=20120217135624.GA3172@redhat.com \
--to=snitzer@redhat.com \
--cc=linux-lvm@redhat.com \
--cc=stuart@bmsi.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.