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

["Lukáš Czerner" <lczerner@redhat.com>]

On Thu, 29 May 2014, Greg KH wrote:

> Date: Thu, 29 May 2014 11:13:19 -0700
> From: Greg KH <greg@kroah.com>
> To: Daniel Phillips <d.phillips@partner.samsung.com>
> Cc: ksummit-discuss@lists.linuxfoundation.org
> Subject: Re: [Ksummit-discuss] [topic] Richer internal block API
> 
> On Thu, May 29, 2014 at 10:49:13AM -0700, Daniel Phillips wrote:
> > Hi Neil,
> > 
> > This will be my annual proposal to open a general discussion about improving
> > the internal block API, to be capable of doing all the things that the ZFS
> > crowd claim are impossible without rampantly violating filesystem/raid
> > layering. Attacking this in a storage-specific venue would also be good,
> > however I view this issue as being at least as central as a number of topics
> > already raised for general consideration.
> 
> Why didn't you bring this up at the filesystem summit a few months ago?
> That's the best place for it, not at the kernel summit.

Actually we've sort-of started the discussion about this topic at
LSF. Dave Chinner was the one who brought this up, the only problem
was that his idea was in really early stage and I suppose it still
is because I have not heard about this since then.

But I agree that this kind of discussion is more suited for LSF
rather than kernel summit since it's much more targeted to block vs.
file systems interactions.

> 
> > Full disclosure dept: I have an agenda. I want to add the equivalent of
> > Raidz etc to Tux3 without reimplementing a logical volume manager in the
> > filesystem.
> 
> Like btrfs is doing?  :)

Well, we want exactly what btrfs is _not_ doing :)

-Lukas

> 
> greg k-h
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>