All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Carlos Maiolino <cmaiolino@redhat.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org
Subject: Re: [LSF/MM TOPIC] Storage: SMR drives
Date: Thu, 16 Jan 2014 12:07:48 -0500	[thread overview]
Message-ID: <20140116170748.GB32391@thunk.org> (raw)
In-Reply-To: <20140116165428.GC3100@orion.maiolino.org>

On Thu, Jan 16, 2014 at 02:54:29PM -0200, Carlos Maiolino wrote:
> 
> I'm not sure if the decision regarding which solution to use (restricted or
> host-aware) was already made (I didn't find any doc specifying it, but in
> either case, having these values properly exported and I'm not sure Ted, if you
> had the idea to describe above all geometry information we'd like to have
> exported, but if you did, one thing I believe to be very important to us is to
> have a way to retrieve the specific location of the random write zones, so
> filesystems can take advantage of this for some specific metadata workloads.

At least initially, it will definitely be host-aware.  Even if we can
make all of our metadata be fully SMR-friendly, it's not going to deal
with random read/write updates.  So it's likely that for ext4, the
first step is to make the metadata be SMR-friendly.  The second step
will be to tweak block allocation to be SMR-friendly.  Only then would
we try to support random writes where in a SMR-friendly way --- and
it's not clear to me it makes sense for us to take things that far,
and that would be a prereq before we could take ext4 to support
restricted mode (aka host-managed SMR).

Part of what we will need to support file systems will indeed be a way
to export geometry information to userspace.

As I noted, I'm also interested in exporting support for the ZBC
commands to userspace, since there may be some use cases where the
application will manage the SMR zones, either using a raw block
device, or using ext4 to manage the large files which are aligned with
SMR zones.

Cheers,

						- Ted

  reply	other threads:[~2014-01-16 17:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-08 16:35 [LSF/MM TOPIC] Storage: SMR drives Theodore Ts'o
2014-01-16 16:54 ` Carlos Maiolino
2014-01-16 17:07   ` Theodore Ts'o [this message]
2014-01-16 18:36   ` [Lsf-pc] " Martin K. Petersen
2014-01-23  5:33     ` Theodore Ts'o

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=20140116170748.GB32391@thunk.org \
    --to=tytso@mit.edu \
    --cc=cmaiolino@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.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.