All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ric Wheeler <rwheeler@redhat.com>
To: Shehbaz Jaffer <shehbazjaffer007@gmail.com>
Cc: Giridhar Yasa <giridhar.yasa@flipkart.com>,
	Sage Weil <sweil@redhat.com>,
	ceph-devel@vger.kernel.org
Subject: Re: [GSoC2016] BlueStore SMR Support
Date: Mon, 14 Mar 2016 13:27:39 -0400	[thread overview]
Message-ID: <56E6F48B.8000301@redhat.com> (raw)
In-Reply-To: <CAPLK-i_BpawhojAjWq6qCy-aEPgG-t-iT0w5tHEFrPvdvusm3A@mail.gmail.com>

On 03/14/2016 12:42 PM, Shehbaz Jaffer wrote:
> Sorry for the late reply.
>
>>>>> Would that be https://github.com/hgst/libzbc from HGST?
> Thanks Giridhar for the link.
>
> Hi Rick,
>
>> Just keep in mind that different vendors have different behaviors - you will
>> need to tweak it I assume to make it act like the drive you are interested
>> in.
> There is a T10 and T13 standardization for interfaces (ZBC and ZAC
> standard). libzbc also follows these standards. From libzbc README
>
> "libzbc implemention is compliant with the latest drafts of
> the ZBC and ZAC standards defined by INCITS technical committee T10 and
> T13 (respectively)."
>
> I plan to keep the scope of the project such that the allocator will
> interact with the libzbc interface in emulated mode which is T10 and
> T13 standard compliant. Once the allocator works on libzbc emulated
> mode, it can run on disks that support ZBC/ZAC commands. Again from
> README.
>
> "In addition to supporting ZBC and ZAC disks, libzbc also implements an
> emulation mode allowing emulating the behavior of a host-managed zoned
> disks using a regular file or a raw standard block device as backing
> storage."
>
>   Is there any other vendor specific behaviour that I should consider?
>
> Thanks,
> Shehbaz
>
>

I think that following the spec is the right way to go. Last time we did a meet 
up with all of the various SMR vendors, they still had a lot of differences in 
how the devices actually worked though (number of zones, how to reset a zone, etc).

If the spec process works thought, this should all hopefully converge :)

Ric


      reply	other threads:[~2016-03-14 17:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 20:06 [GSoC2016] BlueStore SMR Support Shehbaz Jaffer
2016-03-11 14:50 ` Sage Weil
2016-03-12 20:07   ` Giridhar Yasa
2016-03-14 12:17     ` Sage Weil
2016-03-14 12:33       ` Giridhar Yasa
2016-03-14 12:40         ` Sage Weil
2016-03-14 13:22         ` Ric Wheeler
2016-03-14 16:42           ` Shehbaz Jaffer
2016-03-14 17:27             ` Ric Wheeler [this message]

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=56E6F48B.8000301@redhat.com \
    --to=rwheeler@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=giridhar.yasa@flipkart.com \
    --cc=shehbazjaffer007@gmail.com \
    --cc=sweil@redhat.com \
    /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.