[Ksummit-2008-discuss] Suggested topic: possible new API's between file systems and the block layer

Andrew Morton akpm at linux-foundation.org
Sat Jul 26 13:02:00 PDT 2008

On Sat, 26 Jul 2008 14:52:49 -0400 Ric Wheeler <ricwheeler at gmail.com> wrote:

> (Sorry for the possible report - mail troubles...)
> For the past couple of years at the file system & IO workshops, we have
> been grumbling about how limited the communication path is between file
> systems and the block layer is.

We can address those issues better at FAST than at kernel summit.  Far
more of the appropriate individuals are at FAST than are at KS.

I mean, if all we do at FAST is "grumble" then how will rehashing it at
KS improve anything?

> Some examples of things that file systems could leverage would include
> more information about the under lying block device (latency? stripe
> width/alignment? protection level?), better and more robust ways to
> handle errors (btrfs for example can check the underlying IO request,
> detect a bad checksum and would like to be able to ask a mirrored block
> device for "the other copy") and ways to communicate about new types of
> block devices (sparse provisioned luns on arrays want to know which
> block ranges are no longer in use).
> Another broad topic in this area is where to do the RAID code. Again,
> btrfs (and zfs) have moved basic raid up into the file system layer -
> would better api's allow us to avoid this?
> This topic does span several development projects and might be
> contentious enough to stir up some good debate...

I seem to be hearing a lot of silence over support for SSD devices.  I
have this vague worry that there will be a large rollout of SSD
hardware and Linux will be found to have pants-around-ankles.

For example, support for the T13 Trim command.  There will be others,
but I surely don't know what they are.

More information about the Ksummit-2008-discuss mailing list