From: "Matias Bjørling" <m@bjorling.me>
To: Jaegeuk Kim <jaegeuk@kernel.org>, Damien Le Moal <damien.lemoal@wdc.com>
Cc: Slava Dubeyko <Vyacheslav.Dubeyko@wdc.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Viacheslav Dubeyko <slava@dubeyko.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>
Subject: Re: [LSF/MM TOPIC][LSF/MM ATTEND] OCSSDs - SMR, Hierarchical Interface, and Vector I/Os
Date: Fri, 6 Jan 2017 13:55:27 +0100 [thread overview]
Message-ID: <aff717e4-9d1c-fc86-2ad7-2a985113173d@bjorling.me> (raw)
In-Reply-To: <20170106010930.GC2064@jaegeuk.local>
On 01/06/2017 02:09 AM, Jaegeuk Kim wrote:
> Hello,
>
> On 01/04, Damien Le Moal wrote:
>
> ...
>>
>>> Finally, if I really like to develop SMR- or NAND flash oriented file
>>> system then I would like to play with peculiarities of concrete
>>> technologies. And any unified interface will destroy the opportunity
>>> to create the really efficient solution. Finally, if my software
>>> solution is unable to provide some fancy and efficient features then
>>> guys will prefer to use the regular stack (ext4, xfs + block layer).
>>
>> Not necessarily. Again think in terms of device "model" and associated
>> feature set. An FS implementation may decide to support all possible
>> models, with likely a resulting incredible complexity. More likely,
>> similarly with what is happening with SMR, only models that make sense
>> will be supported by FS implementation that can be easily modified.
>> Example again here of f2fs: changes to support SMR were rather simple,
>> whereas the initial effort to support SMR with ext4 was pretty much
>> abandoned as it was too complex to integrate in the existing code while
>> keeping the existing on-disk format.
>
> From the f2fs viewpoint, now we support single host-managed SMR drive having
> a portion of conventional zones. In addition, f2fs supports multiple devices
> [1], which enables us to use pure host-managed SMR which has no conventional
> zone, working with another small conventional partition.
That is a good approach. SSD controllers may even implement a small FTL
inside the device for the "conventional" zones. The size wouldn't be
that big and may only be used to bootstrap rest of the unit. A zone with
a couple hundred megabytes should do. That'll simplify having pblk on
the side next to f2fs.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
WARNING: multiple messages have this Message-ID (diff)
From: "Matias Bjørling" <m@bjorling.me>
To: Jaegeuk Kim <jaegeuk@kernel.org>, Damien Le Moal <damien.lemoal@wdc.com>
Cc: Slava Dubeyko <Vyacheslav.Dubeyko@wdc.com>,
Viacheslav Dubeyko <slava@dubeyko.com>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: [LSF/MM TOPIC][LSF/MM ATTEND] OCSSDs - SMR, Hierarchical Interface, and Vector I/Os
Date: Fri, 6 Jan 2017 13:55:27 +0100 [thread overview]
Message-ID: <aff717e4-9d1c-fc86-2ad7-2a985113173d@bjorling.me> (raw)
In-Reply-To: <20170106010930.GC2064@jaegeuk.local>
On 01/06/2017 02:09 AM, Jaegeuk Kim wrote:
> Hello,
>
> On 01/04, Damien Le Moal wrote:
>
> ...
>>
>>> Finally, if I really like to develop SMR- or NAND flash oriented file
>>> system then I would like to play with peculiarities of concrete
>>> technologies. And any unified interface will destroy the opportunity
>>> to create the really efficient solution. Finally, if my software
>>> solution is unable to provide some fancy and efficient features then
>>> guys will prefer to use the regular stack (ext4, xfs + block layer).
>>
>> Not necessarily. Again think in terms of device "model" and associated
>> feature set. An FS implementation may decide to support all possible
>> models, with likely a resulting incredible complexity. More likely,
>> similarly with what is happening with SMR, only models that make sense
>> will be supported by FS implementation that can be easily modified.
>> Example again here of f2fs: changes to support SMR were rather simple,
>> whereas the initial effort to support SMR with ext4 was pretty much
>> abandoned as it was too complex to integrate in the existing code while
>> keeping the existing on-disk format.
>
> From the f2fs viewpoint, now we support single host-managed SMR drive having
> a portion of conventional zones. In addition, f2fs supports multiple devices
> [1], which enables us to use pure host-managed SMR which has no conventional
> zone, working with another small conventional partition.
That is a good approach. SSD controllers may even implement a small FTL
inside the device for the "conventional" zones. The size wouldn't be
that big and may only be used to bootstrap rest of the unit. A zone with
a couple hundred megabytes should do. That'll simplify having pblk on
the side next to f2fs.
WARNING: multiple messages have this Message-ID (diff)
From: m@bjorling.me (Matias Bjørling)
Subject: [LSF/MM TOPIC][LSF/MM ATTEND] OCSSDs - SMR, Hierarchical Interface, and Vector I/Os
Date: Fri, 6 Jan 2017 13:55:27 +0100 [thread overview]
Message-ID: <aff717e4-9d1c-fc86-2ad7-2a985113173d@bjorling.me> (raw)
In-Reply-To: <20170106010930.GC2064@jaegeuk.local>
On 01/06/2017 02:09 AM, Jaegeuk Kim wrote:
> Hello,
>
> On 01/04, Damien Le Moal wrote:
>
> ...
>>
>>> Finally, if I really like to develop SMR- or NAND flash oriented file
>>> system then I would like to play with peculiarities of concrete
>>> technologies. And any unified interface will destroy the opportunity
>>> to create the really efficient solution. Finally, if my software
>>> solution is unable to provide some fancy and efficient features then
>>> guys will prefer to use the regular stack (ext4, xfs + block layer).
>>
>> Not necessarily. Again think in terms of device "model" and associated
>> feature set. An FS implementation may decide to support all possible
>> models, with likely a resulting incredible complexity. More likely,
>> similarly with what is happening with SMR, only models that make sense
>> will be supported by FS implementation that can be easily modified.
>> Example again here of f2fs: changes to support SMR were rather simple,
>> whereas the initial effort to support SMR with ext4 was pretty much
>> abandoned as it was too complex to integrate in the existing code while
>> keeping the existing on-disk format.
>
> From the f2fs viewpoint, now we support single host-managed SMR drive having
> a portion of conventional zones. In addition, f2fs supports multiple devices
> [1], which enables us to use pure host-managed SMR which has no conventional
> zone, working with another small conventional partition.
That is a good approach. SSD controllers may even implement a small FTL
inside the device for the "conventional" zones. The size wouldn't be
that big and may only be used to bootstrap rest of the unit. A zone with
a couple hundred megabytes should do. That'll simplify having pblk on
the side next to f2fs.
next prev parent reply other threads:[~2017-01-06 12:55 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-02 21:06 [LSF/MM TOPIC][LSF/MM ATTEND] OCSSDs - SMR, Hierarchical Interface, and Vector I/Os Matias Bjørling
2017-01-02 21:06 ` Matias Bjørling
2017-01-02 21:06 ` Matias Bjørling
2017-01-02 23:12 ` Viacheslav Dubeyko
2017-01-02 23:12 ` Viacheslav Dubeyko
2017-01-02 23:12 ` Viacheslav Dubeyko
2017-01-03 8:56 ` Matias Bjørling
2017-01-03 8:56 ` Matias Bjørling
2017-01-03 17:35 ` Viacheslav Dubeyko
2017-01-03 17:35 ` Viacheslav Dubeyko
2017-01-03 17:35 ` Viacheslav Dubeyko
2017-01-03 19:10 ` Matias Bjørling
2017-01-03 19:10 ` Matias Bjørling
2017-01-04 2:59 ` Slava Dubeyko
2017-01-04 2:59 ` Slava Dubeyko
2017-01-04 2:59 ` Slava Dubeyko
2017-01-04 7:24 ` Damien Le Moal
2017-01-04 7:24 ` Damien Le Moal
2017-01-04 12:39 ` Matias Bjørling
2017-01-04 12:39 ` Matias Bjørling
2017-01-04 16:57 ` Theodore Ts'o
2017-01-04 16:57 ` Theodore Ts'o
2017-01-10 1:42 ` Damien Le Moal
2017-01-10 1:42 ` Damien Le Moal
2017-01-10 4:24 ` Theodore Ts'o
2017-01-10 4:24 ` Theodore Ts'o
2017-01-10 13:06 ` Matias Bjorling
2017-01-10 13:06 ` Matias Bjorling
2017-01-11 4:07 ` Damien Le Moal
2017-01-11 4:07 ` Damien Le Moal
2017-01-11 6:06 ` Matias Bjorling
2017-01-11 6:06 ` Matias Bjorling
2017-01-11 7:49 ` Hannes Reinecke
2017-01-11 7:49 ` Hannes Reinecke
2017-01-05 22:58 ` Slava Dubeyko
2017-01-05 22:58 ` Slava Dubeyko
2017-01-05 22:58 ` Slava Dubeyko
2017-01-06 1:11 ` Theodore Ts'o
2017-01-06 1:11 ` Theodore Ts'o
2017-01-06 12:51 ` Matias Bjørling
2017-01-06 12:51 ` Matias Bjørling
2017-01-06 12:51 ` Matias Bjørling
2017-01-09 6:49 ` Slava Dubeyko
2017-01-09 6:49 ` Slava Dubeyko
2017-01-09 6:49 ` Slava Dubeyko
2017-01-09 14:55 ` Theodore Ts'o
2017-01-09 14:55 ` Theodore Ts'o
2017-01-09 14:55 ` Theodore Ts'o
2017-01-06 13:05 ` Matias Bjørling
2017-01-06 13:05 ` Matias Bjørling
2017-01-06 13:05 ` Matias Bjørling
2017-01-06 1:09 ` Jaegeuk Kim
2017-01-06 1:09 ` Jaegeuk Kim
2017-01-06 12:55 ` Matias Bjørling [this message]
2017-01-06 12:55 ` Matias Bjørling
2017-01-06 12:55 ` Matias Bjørling
2017-01-12 1:33 ` [LSF/MM " Damien Le Moal
2017-01-12 2:18 ` [Lsf-pc] " James Bottomley
2017-01-12 2:18 ` James Bottomley
2017-01-12 2:35 ` Damien Le Moal
2017-01-12 2:35 ` Damien Le Moal
2017-01-12 2:38 ` James Bottomley
2017-01-12 2:38 ` James Bottomley
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=aff717e4-9d1c-fc86-2ad7-2a985113173d@bjorling.me \
--to=m@bjorling.me \
--cc=Vyacheslav.Dubeyko@wdc.com \
--cc=damien.lemoal@wdc.com \
--cc=jaegeuk@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=slava@dubeyko.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.