From: Andreas Dilger <adilger@dilger.ca>
To: Theodore Ts'o <tytso@mit.edu>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC] Draft Linux kernel interfaces for SMR/ZBC drives
Date: Wed, 12 Feb 2014 19:08:20 -0700 [thread overview]
Message-ID: <932C36A9-55F9-4221-ACA8-385EE14D124D@dilger.ca> (raw)
In-Reply-To: <20140211195345.GB11971@thunk.org>
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
On Feb 11, 2014, at 12:53 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Tue, Feb 11, 2014 at 12:04:12PM -0700, Andreas Dilger wrote:
>>
>> Should ZBCRESETZONE take a length or number of zones to reset?
>
> I was assuming that we would reset one zone at a time, which I think
> is the main way this would be used.
>
> Thinking about this some more, one other way we could do is to reuse
> BLKDISCARD, with the restriction that the starting LBA (offset) must
> be the first LBA for a zone, and offset + length - 1 must be last LBA
> for a zone. If either of these restrictions are violated, then
> BLKDISCARD would return EINVAL --- or maybe some other error code,
> since EINVAL can also mean an invalid ioctl code.
>
> Hmm... ERANGE would be good, but the strerror(ERANGE) returns "Math
> result not representable", which would be highly confusing, although
> it falls within the grand tradition of confusing Unix error messages,
> such as "not a typewriter". :-)
>
> Any other suggestions?
What about FITRIM? I'm not sure of the exact semantics of ZBCRESETZONE,
but at first glance it seems similar to resetting an erase block on an
SSD. That might also be beneficial if the SMR drives have directly
addressible on-board flash that is mapped to a Z_FLAG_TYPE_RANDOM zone
type (I wish...) and it would pass the FITRIM straight through.
For non-SSD "trim" it would just reset the SMR zone but not return zeroes.
Cheers, Andreas
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2014-02-13 2:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-31 5:38 [RFC] Draft Linux kernel interfaces for ZBC drives Theodore Ts'o
2014-01-31 13:07 ` Matthew Wilcox
2014-01-31 15:44 ` Theodore Ts'o
2014-02-03 21:01 ` Jeff Moyer
2014-02-03 21:07 ` Martin K. Petersen
2014-02-03 21:38 ` Theodore Ts'o
2014-02-03 22:26 ` Jeff Moyer
2014-02-03 21:03 ` Eric Sandeen
2014-02-03 22:17 ` Theodore Ts'o
2014-02-04 2:00 ` HanBin Yoon
2014-02-04 16:27 ` Theodore Ts'o
2014-02-11 18:43 ` [RFC] Draft Linux kernel interfaces for SMR/ZBC drives Theodore Ts'o
2014-02-11 19:04 ` Andreas Dilger
2014-02-11 19:53 ` Theodore Ts'o
2014-02-13 2:08 ` Andreas Dilger [this message]
2014-02-13 3:09 ` Theodore Ts'o
2014-02-21 10:02 ` [RFC] Draft Linux kernel interfaces for ZBC drives Rohan Puri
2014-02-21 15:49 ` Theodore Ts'o
2014-02-25 9:36 ` Rohan Puri
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=932C36A9-55F9-4221-ACA8-385EE14D124D@dilger.ca \
--to=adilger@dilger.ca \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tytso@mit.edu \
/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.