Sage, I really would like to see Ceph kernel client can be built-in the Linux kernel. With this Peta scalable and high performance subsystem, it will benefit to lots of people. It already benefit lots of national laboratories using Ceph in their research lab with industrial common platform in instead of using Sky-high pricing proprietary storage that locks users into the vendor. It gives users the ability to choose the hardware platform they are most comfortable and ability to modify it if needed.
It is the industrial trend no one can stop. History will just repeat itself. This openstorage model will much like Red Hat and Linux did for the server industry in twenty first century. Ceph is one of the important puzzle for this current open storage. If ceph kernel client can be integrate into Linux kernel. It will bring more attention to people and more users will use it and help to develop it. It will make it early into production ready. In the bottom line, this open source and scalable ceph storage bit is what we need in the Linux kernel just like Brtfs in Linux, ZFS in opensolaris. Rocky Shek Product Manager AREA Data Systems 1247 N Lakeview Ave | Suite C | Anaheim | CA | 92807 Tel:(714)993-0300 x118 www.areasys.com -----Original Message----- From: Roland Rabben [mailto:rol...@jotta.no] Sent: Fri 1/1/2010 1:41 PM To: Anton Cc: ceph-devel@lists.sourceforge.net Subject: Re: [ceph-devel] ceph in v2.6.33? I definitly agree with your points Anton. Like you I am silently monitoring this list for signs of production stability. I really like the potential of CEPH and would like to help out getting it into the mainline. Regards Roland Rabben 2009/12/28 Anton <anton.va...@gmail.com> > 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 > > > majord...@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 > > > > > > > ------------------------------------------------------------------------------ > 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 > > -- Roland Rabben Founder & CEO Jotta AS Cell: +47 90 85 85 39 Phone: +47 21 04 29 00 Email: rol...@jotta.no
------------------------------------------------------------------------------ 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
