Linux Device Mapper development
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Jens Axboe <jaxboe@fusionio.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	James Bottomley <James.Bottomley@suse.de>,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Ingo Molnar <mingo@elte.hu>,
	dm-devel@redhat.com, neilb@suse.de
Subject: Re: Please revert a91a2785b20
Date: Tue, 29 Mar 2011 09:42:08 -0400	[thread overview]
Message-ID: <yq1lizyhwlr.fsf@sermon.lab.mkp.net> (raw)
In-Reply-To: <20110329132032.GA22921@redhat.com> (Mike Snitzer's message of "Tue, 29 Mar 2011 09:20:32 -0400")

>>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:

Mike,

Mike> But I think we have a related issue that needs discussion, given
Mike> that an integrity profile mismatch will cause MD's assemble to
Mike> fail (rather than warn and continue to assemble without integrity
Mike> support).

Mike> DM doesn't fail to load a DM device due to a integrity profile
Mike> mismatch; it just emits a warning and continues.

Mike> In contrast, MD will now disallow adding a normal disk (without
Mike> integrity support) to an array that has historically had a
Mike> symmetric integrity profile across all members.

You would invalidate all your existing integrity metadata, tagging,
etc. on existing metadevice members. That seems to be a policy decision,
so if we go down that path it would have to be keyed off a force
assembly option passed down from userland tooling. Turning off features
and/or losing metadata really should not be done without the user's
explicit consent.

Also, let's assume you run an integrity-aware app on a DM device and you
add a non-integrity drive. The DM device is then no longer capable of
carrying integrity metadata out to storage. What happens to the app?
What about outstanding writes with metadata attached?

Good discussion topic for next week, methinks...

-- 
Martin K. Petersen	Oracle Linux Engineering

  parent reply	other threads:[~2011-03-29 13:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LFD.2.00.1103290006070.2774@localhost6.localdomain6>
     [not found] ` <alpine.LFD.2.00.1103290040300.2774@localhost6.localdomain6>
     [not found]   ` <20110328230319.GA12790@redhat.com>
     [not found]     ` <4D918347.7050500@fusionio.com>
2011-03-29 13:20       ` Please revert a91a2785b20 Mike Snitzer
2011-03-29 13:35         ` James Bottomley
2011-03-29 13:42         ` Martin K. Petersen [this message]
2011-03-29 13:58           ` Need to refactor DM's integrity profile support a bit (was: Re: Please revert a91a2785b20) Mike Snitzer
2011-04-01 17:42             ` [PATCH] dm: improve block integrity support Mike Snitzer
2011-04-14 14:09               ` Mike Snitzer
2011-04-14 14:42                 ` Mike Snitzer
2011-04-15  4:57                   ` Martin K. Petersen
2011-04-05  2:09           ` Please revert a91a2785b20 NeilBrown

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=yq1lizyhwlr.fsf@sermon.lab.mkp.net \
    --to=martin.petersen@oracle.com \
    --cc=James.Bottomley@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=dm-devel@redhat.com \
    --cc=jaxboe@fusionio.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=neilb@suse.de \
    --cc=rjw@sisk.pl \
    --cc=snitzer@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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