[Ksummit-2013-discuss] [ATTEND] Kernel Logical Volume Management API

[Daniel Phillips]

On 07/22/2013 02:51 PM, Alasdair G Kergon wrote:
> On Mon, Jul 22, 2013 at 11:53:36AM +0200, Jan Kara wrote:
>>    This is an interesting topic. The fact that we currently have like three
>> or four (not sure about the number now) RAID implementations in kernel
>> suggests we are doing something wrong. Although it might be better suited
>> for LSF or some storage minisummit - it's far easier to get all the
>> interested parties there (compared to KS).
>
> Further development of the original device-mapper raid1 implementation has
> ceased and instead we are now sharing the md implementation and LVM2
> is in the process of switching to using "md wrapped by dm" by default.

Hi Alasdair,

That's great to hear, in fact we (Tux3 team) intend to use md raid as a 
starting point too, because the raid5 and raid6 implementations are 
pretty mature. But see Neil's comments on issues with the device 
creation part of it, that is one place where I think some of the Device 
Mapper ideas could be factored out and made common.

Our main concern is to work towards giving filesystems the ability to 
interface to the raid subsystem in a rich way in order to do RAIDZ types 
of things where the filesystem takes responsibility for tracking volume 
metadata, but without "telescoping" md into the fs, thus hopefully 
ending up with only one core RAID code base to maintain. That we can do 
by ourselves, but the downside would be a "surprise" code dump a few 
years down the road, designed without input from other interested 
parties. Then we would end up with four ways of doing things instead of 
three.

I would rather see a unification effort as a regular thing, not just 
pushed off to a once a year filesystem specific conference which is just 
a passing blip as far as the rest of the community is concerned and and 
generates little follow up. We could possibly divide this into: KS sets 
general priorities with opportunity for all devs to engage FS/MM 
conference makes it happen. FS devs are far from the only ones actually 
having opinions or being affected by this.

That has been a big part of the problem: volume management is 
perennially regarded as a red headed stepchild who gets to sleep under 
the steps. Linus gives it a big yawn, Jon rarely has much to write 
about. This approach has not worked well to date, judging by the rate of 
progress. The last serious burst of progress was more than ten years 
ago. I am suggesting that it is high time to get serious. On the list of 
things that still suck about Linux, this has to rank near the top.

By analogy, this process would resemble the way IDE was eventually 
replaced by generalized SCSI, with similar benefits just in terms of 
maintainability, but also working towards a real "unixy" answer to the 
awful travesty of the ZFS bloated black box philosophy of filesystem design.

Regards,

Daniel