From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <keith.busch@intel.com>
Cc: Jens Axboe <axboe@fb.com>,
linux-api@vger.kernel.org, dm-devel@redhat.com,
linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: Persistent Reservation API V2
Date: Fri, 21 Aug 2015 08:59:54 +0200 [thread overview]
Message-ID: <20150821065954.GA14559@lst.de> (raw)
In-Reply-To: <alpine.LNX.2.00.1508202317270.15930@localhost.lm.intel.com>
On Thu, Aug 20, 2015 at 11:56:36PM +0000, Keith Busch wrote:
> NVMe can also specify
> if whether or not a reservation should persist through power-loss.
SCSI does as well, it's the APTPL flag. However reservations not persistent
through a power loss are basically useless, so I decided to force them on
in the API. From the documentation:
"All implementations are expected to ensure the reservations survive
a power loss"
So I would prefer not to add it, or if we really have to as a negative flag
to specifically opt out of the APTPL behavior.
> with it. For example, NVMe can ignore existing keys when acquiring a
> reservation in addition to registering a new key.
This sounds like a sensible addition to me, and I wouldn't be surprised
if future SPC versions will add this flag.
WARNING: multiple messages have this Message-ID (diff)
From: hch@lst.de (Christoph Hellwig)
Subject: Persistent Reservation API V2
Date: Fri, 21 Aug 2015 08:59:54 +0200 [thread overview]
Message-ID: <20150821065954.GA14559@lst.de> (raw)
In-Reply-To: <alpine.LNX.2.00.1508202317270.15930@localhost.lm.intel.com>
On Thu, Aug 20, 2015@11:56:36PM +0000, Keith Busch wrote:
> NVMe can also specify
> if whether or not a reservation should persist through power-loss.
SCSI does as well, it's the APTPL flag. However reservations not persistent
through a power loss are basically useless, so I decided to force them on
in the API. From the documentation:
"All implementations are expected to ensure the reservations survive
a power loss"
So I would prefer not to add it, or if we really have to as a negative flag
to specifically opt out of the APTPL behavior.
> with it. For example, NVMe can ignore existing keys when acquiring a
> reservation in addition to registering a new key.
This sounds like a sensible addition to me, and I wouldn't be surprised
if future SPC versions will add this flag.
next prev parent reply other threads:[~2015-08-21 6:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 6:23 Persistent Reservation API V2 Christoph Hellwig
2015-08-12 6:23 ` Christoph Hellwig
2015-08-12 6:23 ` Christoph Hellwig
2015-08-12 6:23 ` [PATCH 1/5] block: cleanup blkdev_ioctl Christoph Hellwig
2015-08-12 6:23 ` Christoph Hellwig
2015-08-12 6:23 ` [PATCH 2/5] block: add an API for Persistent Reservations Christoph Hellwig
2015-08-12 6:23 ` Christoph Hellwig
2015-08-12 6:23 ` [PATCH 3/5] sd: implement the Persistent Reservation API Christoph Hellwig
2015-08-12 6:23 ` Christoph Hellwig
2015-08-12 6:23 ` [PATCH 4/5] dm: refactor ioctl handling Christoph Hellwig
2015-08-12 6:23 ` Christoph Hellwig
2015-08-12 6:23 ` [PATCH 5/5] dm: add support for passing through persistent reservations Christoph Hellwig
2015-08-12 6:23 ` Christoph Hellwig
2015-08-17 19:13 ` Persistent Reservation API V2 Christoph Hellwig
2015-08-17 19:13 ` Christoph Hellwig
2015-08-18 17:58 ` Jens Axboe
2015-08-18 17:58 ` Jens Axboe
2015-08-18 17:58 ` Jens Axboe
[not found] ` <1439360604-16192-1-git-send-email-hch-jcswGhMUV9g@public.gmane.org>
2015-08-20 23:56 ` Keith Busch
2015-08-20 23:56 ` Keith Busch
2015-08-20 23:56 ` Keith Busch
2015-08-21 6:59 ` Christoph Hellwig [this message]
2015-08-21 6:59 ` Christoph Hellwig
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=20150821065954.GA14559@lst.de \
--to=hch@lst.de \
--cc=axboe@fb.com \
--cc=dm-devel@redhat.com \
--cc=keith.busch@intel.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.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 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.