From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: [RFC] Draft Linux kernel interfaces for ZBC drives Date: Mon, 3 Feb 2014 17:17:00 -0500 Message-ID: <20140203221700.GC22856@thunk.org> References: <52F00406.3020301@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Eric Sandeen Return-path: Received: from imap.thunk.org ([74.207.234.97]:53870 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752160AbaBCWRE (ORCPT ); Mon, 3 Feb 2014 17:17:04 -0500 Content-Disposition: inline In-Reply-To: <52F00406.3020301@sandeen.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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