Re: [Ksummit-discuss] [topic] Richer internal block API

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2014-06-02 at 13:33 -0400, Martin K. Petersen wrote:
> >>>>> "Greg" == Greg KH <greg@kroah.com> writes:
> 
> >> Perhaps there is something wrong with that approach. Certainly in
> >> regards to how to bridge the gap between what we now have for logical
> >> volume support, and what we should have, or what BSD has, that
> >> approach is demonstrably a perennial failure. After all these years,
> >> we still have dm and md as separate islands, no usable snapshotting
> >> block device, and roughly zero interaction between filesystems and
> >> volume managers.
> 
> Greg> People have talked about this for over a very long time.  

Agreed; KS would never be the right venue for this, it's a LSF topic.

> Lots of talking, indeed. But I think the main problem that there's
> nothing (or very little) to see here. Move along :)
> 
> Either you let the filesystem explicitly manage RAID and snapshots (like
> btrfs) or you let DM or MD do it behind the filesystem's back. What's
> the point of introducing a new interface to do something that we already
> have?
> 
> That doesn't mean that there isn't merit to the "given this cookie, do
> you happen to have another copy?" call we have discussed in the past.
> Somebody just needs to do it. But I honestly think that btrfs is a much
> better approach to that whole thing...

We actually tried RAID unification between btrfs and dm and md a long
time ago.  We did make some progress with dm and md, but the use
paradigm of btrfs is just a bit too different and it couldn't be made to
work without making a huge mess.  What's happening now is that we're
looking at the token and descriptor APIs (mostly for copy offload) and
if we find a good one we could revisit the issue and see if there's
other things it might support.

When I was a kid, I used to love architecture (in the software sense)
because it looked like blue printing the perfect edifice in advance and
then just putting the bricks in.  Now that I'm older, I far prefer
having a set of abstractions that make an outline and being guided by
how the pieces fit together because that leaves you open to things the
perfect architecture approach forces you to ignore and it fits well with
the Linux code and use case requirements.

I'm sure when the use case finally arrives we'll be able to refactor
around it, but I don't think it's quite here yet.

James