From: Walker, Benjamin <benjamin.walker at intel.com>
To: spdk@lists.01.org
Subject: Re: [SPDK] Bdev claim and single writer semantics
Date: Mon, 30 Apr 2018 17:24:00 +0000 [thread overview]
Message-ID: <1525109039.2609.23.camel@intel.com> (raw)
In-Reply-To: CANvN+ek6SG6XPdze4Rs2OaiFoFAuC=gDmVuwa9wZRdLPgXsMVw@mail.gmail.com
[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
On Sat, 2018-04-28 at 21:30 +0000, Andrey Kuzmin wrote:
> While adding support for the shared access semantics seems to be
> pretty straightforward, I thought it reasonable to bring the issue up
> here first, looking for insights, comments, and objections. Please let
> me know if there are any or I can give a shot to a shared access
> patch.
On Sat, Apr 28, 2018, 02:06 Harris, James R <james.r.harris(a)intel.com> wrote:
> I’m wondering if we should just remove the safety check. The original concern
> was to prevent the overwriting of metadata. For example, an NVMe bdev
> contains a logical volume store – the lvol bdev module has claimed the bdev,
> opening and writing directly to the NVMe bdev could corrupt the metadata.
>
> But I agree there are a lot of use cases where you may still want to allow
> this for one reason or another. And the Linux kernel doesn’t try to prevent
> this – you can put an LVM PV/VG on a block device and then write zeroes to the
> underlying block device. Same with using parted to put down a GPT and
> creating a partition.
Based on the behavior of other similar block stacks, I'm on board with just
entirely removing the check. I vote we entirely decouple claiming (building the
block device dependency tree) from descriptors (read/write permission checks).
Thanks,
Ben
next reply other threads:[~2018-04-30 17:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 17:24 Walker, Benjamin [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-05-09 21:57 [SPDK] Bdev claim and single writer semantics Walker, Benjamin
2018-05-09 17:58 Andrey Kuzmin
2018-05-09 17:32 Walker, Benjamin
2018-05-09 8:12 Andrey Kuzmin
2018-05-02 22:07 Andrey Kuzmin
2018-05-02 16:45 Walker, Benjamin
2018-05-02 13:58 Luse, Paul E
2018-05-02 13:40 Andrey Kuzmin
2018-04-30 17:26 Andrey Kuzmin
2018-04-28 21:35 Andrey Kuzmin
2018-04-28 21:30 Andrey Kuzmin
2018-04-28 21:13 Luse, Paul E
2018-04-27 23:06 Harris, James R
2018-04-27 15:04 Andrey Kuzmin
2018-04-26 23:26 Walker, Benjamin
2018-04-26 12:25 Andrey Kuzmin
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=1525109039.2609.23.camel@intel.com \
--to=spdk@lists.01.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.