Ideas for supporting shingled magnetic recording (SMR)

> The reason for this is quite simple: the classic block device
> interfaces does not provide everything BTRFS and ZFS need.

That's exactly the point that I made in the presentation that the article was talking about. i.e. the "classic block device" doesn't have the functionality needed to handle SMR properly, and neither do "traditional filesystems". The whole point of the discussion we had was to understand if we could extend the "classic block device" to provide the functionality we need to support SMR devices....

IOWS, we're now in a situation where we need a richer, smarter block device. However, instead of just plugging into the infrastructure we should have put into place for btrfs years ago, we don't have anything we can use. That's the architectural mistake we made with btrfs years ago. Hence now we have to provide a generic "smart block device" despite the fact that btrfs has that functionality internally. We can't use any of the btrfs functionality precisely because it's not generic and is deeply tied to the internal BTRFS structure.

> you would have a hard time convincing enterprise users to trust
> their data to the new and unproven block device code,
> when the old and proven version can is perfectly capable to host
> their ext3 file system...

ext3 will *not work at all* on the host-aware/host-managed SMR drives that vendors will ship. Users will have no choice but to use something other than ext3 on their host-aware/managed SMR drives.

-Dave.