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

[Ric Wheeler]

(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.

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...

ric