From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [LSF/MM TOPIC][LSF/MM ATTEND] OCSSDs - SMR, Hierarchical Interface, and Vector I/Os To: Jaegeuk Kim , Damien Le Moal References: <05204e9d-ed4d-f97a-88f0-41b5e008af43@bjorling.me> <1483398761.2440.4.camel@dubeyko.com> <1483464921.2440.19.camel@dubeyko.com> <9319ce16-8355-3560-95b6-45e3f07220de@bjorling.me> <20170106010930.GC2064@jaegeuk.local> From: =?UTF-8?Q?Matias_Bj=c3=b8rling?= Message-ID: Date: Fri, 6 Jan 2017 13:55:27 +0100 MIME-Version: 1.0 In-Reply-To: <20170106010930.GC2064@jaegeuk.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Slava Dubeyko , "linux-nvme@lists.infradead.org" , "linux-block@vger.kernel.org" , Viacheslav Dubeyko , Linux FS Devel , "lsf-pc@lists.linux-foundation.org" Content-Type: text/plain; charset="us-ascii" Sender: "Linux-nvme" Errors-To: linux-nvme-bounces+axboe=kernel.dk@lists.infradead.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f68.google.com ([74.125.82.68]:35022 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752391AbdAFNXU (ORCPT ); Fri, 6 Jan 2017 08:23:20 -0500 Received: by mail-wm0-f68.google.com with SMTP id l2so5006286wml.2 for ; Fri, 06 Jan 2017 05:23:19 -0800 (PST) Subject: Re: [LSF/MM TOPIC][LSF/MM ATTEND] OCSSDs - SMR, Hierarchical Interface, and Vector I/Os To: Jaegeuk Kim , Damien Le Moal References: <05204e9d-ed4d-f97a-88f0-41b5e008af43@bjorling.me> <1483398761.2440.4.camel@dubeyko.com> <1483464921.2440.19.camel@dubeyko.com> <9319ce16-8355-3560-95b6-45e3f07220de@bjorling.me> <20170106010930.GC2064@jaegeuk.local> Cc: Slava Dubeyko , Viacheslav Dubeyko , "lsf-pc@lists.linux-foundation.org" , Linux FS Devel , "linux-block@vger.kernel.org" , "linux-nvme@lists.infradead.org" From: =?UTF-8?Q?Matias_Bj=c3=b8rling?= Message-ID: Date: Fri, 6 Jan 2017 13:55:27 +0100 MIME-Version: 1.0 In-Reply-To: <20170106010930.GC2064@jaegeuk.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: m@bjorling.me (=?UTF-8?Q?Matias_Bj=c3=b8rling?=) Date: Fri, 6 Jan 2017 13:55:27 +0100 Subject: [LSF/MM TOPIC][LSF/MM ATTEND] OCSSDs - SMR, Hierarchical Interface, and Vector I/Os In-Reply-To: <20170106010930.GC2064@jaegeuk.local> References: <05204e9d-ed4d-f97a-88f0-41b5e008af43@bjorling.me> <1483398761.2440.4.camel@dubeyko.com> <1483464921.2440.19.camel@dubeyko.com> <9319ce16-8355-3560-95b6-45e3f07220de@bjorling.me> <20170106010930.GC2064@jaegeuk.local> Message-ID: 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.