ceph in v2.6.33?

ceph in v2.6.33?

[Sage Weil]

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 

Re: ceph in v2.6.33?

[Rocky Shek]

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 with 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: Sage Weil [mailto:sage@newdream.net] 
Sent: Monday, December 21, 2009 9:07 AM
To: ceph-devel@lists.sf.net
Subject: [ceph-devel] ceph in v2.6.33?

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

------------------------------------------------------------------------------
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 

Re: ceph in v2.6.33?

[Anton]

[-- 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

Re: ceph in v2.6.33?

[Sage Weil]

On Mon, 28 Dec 2009, Anton wrote:
> 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.

We have a few disk format changes planned for the next week or two (mainly 
compat/incompat flags to making future changes easier), but once those are 
in we could really use some wider testing.  Our list of known bugs is 
shrinking and it's getting hard to break things.  Getting more users 
trying the system out will both help with the development and stability 
effort and demonstrate the kind of interest Linus is looking for.

sage

------------------------------------------------------------------------------
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 

Re: ceph in v2.6.33?

[Roland Rabben]

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

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.vazir@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
> > > 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
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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: roland@jotta.no

[-- Attachment #1.2: Type: text/html, Size: 8464 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

Re: ceph in v2.6.33?

[Rocky Shek]

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


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:roland@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.vazir@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
> > > 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
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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: roland@jotta.no


[-- Attachment #1.2: Type: text/html, Size: 10199 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

Re: ceph in v2.6.33?

[Joe Landman]

Sage:

   We (my company) have been following Ceph for a while.  We are looking 
forward to being able to offer this as part of our siCluster storage 
cluster offering.

   Let me know if a note to Linus/LKML would help.  We would like to see 
the code in the kernel (we roll our own kernels for support/performance 
reasons).

   Regards,

Joe

-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics, Inc.
email: landman@scalableinformatics.com
web  : http://scalableinformatics.com
        http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax  : +1 866 888 3112
cell : +1 734 612 4615

------------------------------------------------------------------------------
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 

Re: ceph in v2.6.33?

[Andi Kleen]

Joe Landman <landman@scalableinformatics.com> writes:

> Sage:
>
>    We (my company) have been following Ceph for a while.  We are looking 
> forward to being able to offer this as part of our siCluster storage 
> cluster offering.
>
>    Let me know if a note to Linus/LKML would help.  We would like to see 
> the code in the kernel (we roll our own kernels for support/performance 
> reasons).

The interesting question is if you actually use it. Do you?

Linus asked for a user-base.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

------------------------------------------------------------------------------
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 

Re: ceph in v2.6.33?

[Joe Landman]

Andi Kleen wrote:
> Joe Landman <landman@scalableinformatics.com> writes:
> 
>> Sage:
>>
>>    We (my company) have been following Ceph for a while.  We are looking 
>> forward to being able to offer this as part of our siCluster storage 
>> cluster offering.
>>
>>    Let me know if a note to Linus/LKML would help.  We would like to see 
>> the code in the kernel (we roll our own kernels for support/performance 
>> reasons).
> 
> The interesting question is if you actually use it. Do you?

Hi Andi

   We've had a few systems with it set up in the recent past (within the 
last 2 months), but they are our lab/demo/engineering systems for 
testing things, and they are out at customer sites right now running 
other tools.

   We have had, and continue to have testing going on with Ceph, BTRFS, 
NILFS2.  We actively use and support glusterfs, and have customers using 
Lustre, PVFS2, and others.  We have been looking at pohmelfs and others 
as potentially interesting.

   So, yes, we have used it for testing purposes, hence our interest in 
seeing it included.

Joe

> 
> Linus asked for a user-base.
> 
> -Andi


-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics Inc.
email: landman@scalableinformatics.com
web  : http://scalableinformatics.com
        http://scalableinformatics.com/jackrabbit
phone: +1 734 786 8423 x121
fax  : +1 866 888 3112
cell : +1 734 612 4615

------------------------------------------------------------------------------
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 

Re: ceph in v2.6.33?

[Dallas Kashuba]

On Jan 4, 2010, at 7:02 AM, Joe Landman wrote:

> Andi Kleen wrote:
>> Joe Landman <landman@scalableinformatics.com> writes:
>> 
>>> Sage:
>>> 
>>>   We (my company) have been following Ceph for a while.  We are looking 
>>> forward to being able to offer this as part of our siCluster storage 
>>> cluster offering.
>>> 
>>>   Let me know if a note to Linus/LKML would help.  We would like to see 
>>> the code in the kernel (we roll our own kernels for support/performance 
>>> reasons).
>> 
>> The interesting question is if you actually use it. Do you?
> 
> Hi Andi
> 
>   We've had a few systems with it set up in the recent past (within the 
> last 2 months), but they are our lab/demo/engineering systems for 
> testing things, and they are out at customer sites right now running 
> other tools.
> 
>   We have had, and continue to have testing going on with Ceph, BTRFS, 
> NILFS2.  We actively use and support glusterfs, and have customers using 
> Lustre, PVFS2, and others.  We have been looking at pohmelfs and others 
> as potentially interesting.
> 
>   So, yes, we have used it for testing purposes, hence our interest in 
> seeing it included.
> 
> Joe


How has your testing been going with it?  Have you been bumping into many problems?

 - Dallas


>> 
>> Linus asked for a user-base.
>> 
>> -Andi
> 
> 
> -- 
> Joseph Landman, Ph.D
> Founder and CEO
> Scalable Informatics Inc.
> email: landman@scalableinformatics.com
> web  : http://scalableinformatics.com
>        http://scalableinformatics.com/jackrabbit
> phone: +1 734 786 8423 x121
> fax  : +1 866 888 3112
> cell : +1 734 612 4615
> 


------------------------------------------------------------------------------
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 

Re: ceph in v2.6.33?

[Jerker Nyberg]

I have used Ceph for some time for evaluation on computional clusters. I 
administrate a small cluster (one rack) at a department at our university 
running MOSIX using NFS as a file server. I am very intrested in migrating 
to Ceph if stable enough and performance for our applications are better 
than NFS.

The main proprietary competitor is Panasas. Our university recently bought 
a rack for use with the university central computing resources. The other 
open source project I am looking at is GlusterFS, but I prefer the 
architecture of Ceph.

I agree that it would be nice to have Ceph client in the kernel tree but 
maybe more important is to get packages for the major distributions (RHEL 
with clones etc) which in time, when Ceph stabilize and get more users, 
might be lifted into the actual distributions. Then putting client into 
kernel is only a small step.

Regards,
Jerker Nyberg.


------------------------------------------------------------------------------
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