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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
