|
|
Log in / Subscribe / Register

Ideas for supporting shingled magnetic recording (SMR)

Ideas for supporting shingled magnetic recording (SMR)

Posted Apr 4, 2014 1:15 UTC (Fri) by PaulWay (guest, #45600)
Parent article: Ideas for supporting shingled magnetic recording (SMR)

It sounds to me like this is actually going to require a completely separate file system:

* One "random access" section (could be small) which contains all the metadata.

* Multiple 'log' sections where data is copied on write.

Remember that you can overwrite a part of a shingled section as long as you rewrite all the data after where you start writing. You can also resume writing from the place you left off with no penalty. It sounds like a drive might have many hundreds of these sections, so picking a 'log' section to write your latest update to your file or block isn't a huge penalty. And you can random-access read from anywhere, shingled or standard.

So each time you want to rewrite something, you create a new entry in the log section, then point to that in the random access section which holds your metadata. File systems can be rebuilt by replaying each of these log sections internally.

It seems to me that trying to make some kind of 'interface layer' which allows an SMR drive to be treated as a normal drive - whether it's in the kernel or on the drive - is a great way to kill performance. The methods that are going to work are methods that use the drive's native capabilities to their advantage.

(Likewise, I can imagine a standard extent-based system having a 'compatibility layer' underneath them on the device that maps virtual sectors into real ones, to make a host-managed device seem like it's not shingled. But again I think it's going to immediately start costing a lot of performance.)

Have fun,

Paul


to post comments


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds