Re: [SPDK] Bdev claim and single writer semantics

[Andrey Kuzmin <andrey.v.kuzmin at gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3421 bytes --]

On Sun, Apr 29, 2018, 00:14 Luse, Paul E <paul.e.luse(a)intel.com> wrote:

> Maybe make the check a compilation option and default to off? That makes
> it very clear that it’s a consideration at least and easy to flip it
> however depending...
>

Whatever the mechanism - compile- or configuration time - there still will
be some coding involved, either making some code conditional or checking
the config option at runtime. Personally, I think compile-time is best
suited for configuring the build rather than the installation. Just my $.02.

Regards,
Andrey

>
> Thx
> Paul
>
> -----Original Message-----
> From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Harris, James R
> Sent: Friday, April 27, 2018 4:06 PM
> To: Storage Performance Development Kit <spdk(a)lists.01.org>
> Subject: Re: [SPDK] Bdev claim and single writer semantics
>
>
>
> On 4/27/18, 8:04 AM, "SPDK on behalf of Andrey Kuzmin" <
> spdk-bounces(a)lists.01.org on behalf of andrey.v.kuzmin(a)gmail.com> wrote:
>
>     On Fri, Apr 27, 2018 at 2:26 AM, Walker, Benjamin
>     <benjamin.walker(a)intel.com> wrote:
>     > On Thu, 2018-04-26 at 15:25 +0300, Andrey Kuzmin wrote:
>     >> Hi all,
>   >>
>
> <snip>
>
>     >> 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.
>     >
>     > Your analysis is all correct. There are two access control
> mechanisms in the
>     > bdev layer for different purposes; claiming, which is for stacking
> bdevs
>     > together to make I/O pipelines, and descriptors, which is standard
> read/write
>     > access control for consumers of bdevs. We thought it made the most
> sense to
>     > allow write access to a bdev from only a single module for safety
> reasons.
>
>     What seems to be a fairly reasonable safety measure for a
> general-purpose
>     I/O stack can easily become an unwarranted constraint in a
> tightly-controlled
>     (say, appliance) settings. Turning single writer into a stack-level
>     configurable
>     option could buy us the best of both worlds at once.
>
> 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.
>
> So basically, it’s up to the user to know what they are doing.
>
> -Jim
>
>
>
>
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
> _______________________________________________
> SPDK mailing list
> SPDK(a)lists.01.org
> https://lists.01.org/mailman/listinfo/spdk
>
-- 

Regards,
Andrey

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4670 bytes --]