linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: Spelic <spelic@shiftmail.org>, linux-lvm@redhat.com
Subject: Re: [linux-lvm] Still missing for supporting dm-thin
Date: Tue, 26 Jun 2012 11:11:50 +0200	[thread overview]
Message-ID: <4FE97CD6.70707@redhat.com> (raw)
In-Reply-To: <20120625162703.GC17857@agk-dp.fab.redhat.com>

Dne 25.6.2012 18:27, Alasdair G Kergon napsal(a):
> On Mon, Jun 25, 2012 at 04:34:52PM +0200, Spelic wrote:
>> 1) It is not possible to backup and restore a VG config (vgcfgrestore in
>> particular refuses to work) if there is a dm-thin volume. This is a very
>> serious problem that does not allow to recover even non-thin volumes if
>> there is a thin volume around. Even automatic backups from
>> /etc/lvm/archive cannot be restored/used. This puts data at risk, please
>> fix this.
>
> We do want to find a way to do this for non-thin volumes - the current
> restrictions are indeed tighter than they need to be.
>
> For thin volumes though it's a complex problem to work out what can
> be restored safely and what can't.  (The metadata saying where a volume is is
> now split between the LVM metadata and the thin metadata.)

We need history also for all LVs used by thin-pool - so currently the safest
is to disable restore until we are sure we could provide some solution, where 
the user does not easily break whole VG in non-repairable way.

>
>> 2) less important: it is apparently not possible to change the --zero
>> flag for a thin pool once created.
>
> That should be just another lvchange parameter.
>


While going from  --zero mode to non zero is quite ok, the opposite direction 
might have unexpected side effects.

If the block were provisioned in the non-zero mode - they may have random pool 
content on unwritten data areas - thus if user may arbitrarily switch between 
zeroing type - the content would be unpredictable, and we would need to keep 
this as some history flag - once the pool was started without zeroing,
we may not guarantee, provisioned unwritten data blocks will have zero 
content.  So for full support we have to make clear, how we will keep history 
info - i.e. to avoid bugreports where the weird data will be received in the 
zero mode.  (something like tainted kernel ?)

It is getting even more complex when I play with discard options...

Zdenek

  reply	other threads:[~2012-06-26  9:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-25 14:34 [linux-lvm] Still missing for supporting dm-thin Spelic
2012-06-25 16:27 ` Alasdair G Kergon
2012-06-26  9:11   ` Zdenek Kabelac [this message]
2012-06-28 12:16     ` Spelic

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=4FE97CD6.70707@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=spelic@shiftmail.org \
    /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).