Re: ceph in v2.6.33?

[Anton <anton.vazir@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4974 bytes --]

FS with CEPH abilities is the LOOOOONG time awaited stuff, 
which I (personally) looking so much forward to stabilize - 
that it could be hardly expressed. I't not widelly known 
yet, but I think a lot of us, who needs clustered storage 
and did own survey of the cluster FS stuff available (like 
gluster, etc) - just siletntly monitor the list for the 
signs that code is stable enough to be used in the 
production. How should we show our demand fo Linus? I would 
really like to see kernel supporting  CEPH in the mainline.

On Monday 21 December 2009, Sage Weil wrote:
> The Ceph kernel client may not make it into .33 after
> all... in the absense of other issues, Linus would like
> to see some user demand before merging a new subsystem. 
> If you'd like to see it in mainline sooner, now's the
> time to speak up.
>
> Either way, this doesn't change too much for us.  We're
> still focusing in improving stability and fixing osd
> performance problems, and not much else.  The disk format
> and wire protocol are very nearly stabilized.  An earlier
> merge would make it easier for people to test the system,
> but pulling the client from the ceph tree or building the
> standalone module will make it easier for us to manage
> bug fixes.
>
> sage
>
> On Fri, 18 Dec 2009, Linus Torvalds wrote:
> > On Fri, 18 Dec 2009, Sage Weil wrote:
> > > I would still like to see ceph merged for 2.6.33. 
> > > It's certainly not production ready, but it would be
> > > greatly beneficial to be in mainline for the same
> > > reasons other file systems like btrfs and exofs were
> > > merged early.
> >
> > So what happened to ceph is the same thing that
> > happened to the alacrityvm pull request (Greg Haskins
> > added to cc): I pretty much continually had a _lot_ of
> > pull requests, and all the time the priority for the
> > ceph and alactrityvm pull requests were just low enough
> > on my priority list that I never felt I had the reason
> > to look into the background enough to make an even
> > half-assed decision of whether to pull or not.
> >
> > And no, "just pull" is not my default answer - if I
> > don't have a reason, the default action is "don't
> > pull".
> >
> > I used to say that "my job is to say 'no'", although
> > I've been so good at farming out submaintainers that
> > most of the time my real job is to pull from
> > submaintainers who hopefully know how to say 'no'. But
> > when it comes to whole new driver features, I'm still
> > "no by default - tell me _why_ I should pull".
> >
> > So what is a new subsystem person to do?
> >
> > The best thing to do is to try to have users that are
> > vocal about the feature, and talk about how great it
> > is. Some advocates for it, in other words. Just a few
> > other people saying "hey, I use this, it's great", is
> > actually a big deal to me. For alacrityvm and cephfs, I
> > didn't have that, or they just weren't loud enough for
> > me to hear.
> >
> > So since you mentioned btrfs as an "early merge", I'll
> > mention it too, as a great example of how something got
> > merged early because it had easily gotten past my
> > "people are asking for it" filter, to the point where
> > _I_ was interested in trying it out personally, and
> > asking Chris&co to tell me when it was ready.
> >
> > Ok, so that was somewhat unusual - I'm not suggesting
> > you'd need to try to drum up quite _that_ much hype -
> > but it kind of illustrates the opposite extreme of your
> > issue. Get some PR going, get people talking about it,
> > get people testing it out. Get people outside of your
> > area saying "hey, I use it, and I hate having to merge
> > it every release".
> >
> > Then, when I see a pull request during the merge
> > window, the pull suddenly has a much higher priority,
> > and I go "Ok, I know people are using this".
> >
> > So no astro-turfing, but real grass-roots support
> > really does help (or top-down feedback for that matter
> > - if a _distribution_ says "we're going to merge this
> > in our distro regardless", that also counts as a big
> > hint for me that people actually expect to use it and
> > would like to not go through the pain of merging).
> >
> > 			Linus
> > --
> > To unsubscribe from this list: send the line
> > "unsubscribe linux-fsdevel" in the body of a message to
> > majordomo@vger.kernel.org More majordomo info at 
> > http://vger.kernel.org/majordomo-info.html
>
> ---------------------------------------------------------
>--------------------- This SF.Net email is sponsored by
> the Verizon Developer Community Take advantage of
> Verizon's best-in-class app development support A
> streamlined, 14 day to market process makes app
> distribution fast and easy Join now and get one step
> closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Ceph-devel mailing list
> Ceph-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ceph-devel




[-- Attachment #1.2: Type: text/html, Size: 6893 bytes --]

[-- Attachment #2: Type: text/plain, Size: 390 bytes --]

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Ceph-devel mailing list
Ceph-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ceph-devel