On Mon, Feb 03, 2014 at 03:03:02PM -0600, Eric Sandeen wrote:
>
> Just to flesh out the context for these a bit, what do you envision as the
> consumer of these interfaces? Things in the block layer? A DM target?
> Existing filesystems? A new filesystem?
All of the above. In addition, I propose to expose this interface via
an ioctl for block devices since there may be userspace applications
that want to be manage the SMR directly from user space. It would
also be used by ext4 to better align the journal (Project ext4-01 in
the SMR project spreadsheet).
I also want to make the same ioctl exposed for an ext4 file where all
of its blocks cover SMR zones directly --- that is some of the
motivation for the mke2fs mk_hugefile functionality that I've been
working on, since I have specific userspace use case in mind for that,
where we want to get both the management advantages of an file system
but the userspace application might want to treat one or more huge
files as a miniature SMR disk(s).
> I suppose we'll need an interface similar to this at whatever layer has
> to deal with it. I've got my own opinions on where we might handle
> it (IMHO, retrofitting 3 or 4 major filesystems sounds like more
> than really want to take on), but it'd be nice to know what you're
> thinking here.
Well, even if we have a device mapper shim layer which takes a
restricted mode SMR drive and handles the indirection layer
(i.e. projects Core-05 and Core-06) I think is a good thing, it still
might be a good idea to have the file system's block allocation system
make the block allocations to be more SMR-friendly. Similarly, we
might use something like the very lazy journal updates (Ext4-02) to
make life easier for the shim layer, as well as using this interface
so we can better make block allocation decisions (Ext4-03).
So my vision for ext4 is not that it would ever be able to be
completely able to use restricted mode SMR drives directly. I expect
that we would use either run on drives that implement cooperative
(host aware) SMR mode, or on top of a device mapper ship that provided
cooperative mode layered on top of a restricted mode SMR drive. So I
wouldn't call this a "massive retrofitting" of ext4, but just some
medium-sized changes that would make ext4 more SMR friendly. Some of
these changes, such as the lazy journal updates, should also improve
performance for HDD and especially for eMMC flash storage.
And it may very well be that not all file systems will want to put in
the work to make them more SMR friendly, and that's fine. Just as
ext4 hasn't really focused on supporting massive RAID arrays, and
that's OK, because users can always use XFS for that --- similarily,
it may be completely rational for the XFS developers to decide that it
doesn't make sense for them worry about making XFS SMR-aware.
Cheers,
- Ted
--
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
