Greetings All!
Time for another Storage SIG meeting [1] ( We are following a bi-weekly schedule) . But I forgot to announce it yesterday. Sorry for the inconvenience caused. Let me know if it is too late to announce the meeting (in that case we can cancel this meeting).
We will be meeting in #centos-devel on Freenode.
Agenda: #info Topic: Action items from previous meeting #info Topic: Status Updates #info Subtopic: GlusterFS #info Subtopic: OpenAFS #info Subtopic: Ceph #info Subtopic: SCST #info Open Floor
Thanks, Lala
Rescheduling the meeting to next week as others might not have an opportunity to read the meeting reminder for today.
Thanks, Lala
On 03/06/2015 06:46 AM, Lalatendu Mohanty wrote:
Greetings All!
Time for another Storage SIG meeting [1] ( We are following a bi-weekly schedule) . But I forgot to announce it yesterday. Sorry for the inconvenience caused. Let me know if it is too late to announce the meeting (in that case we can cancel this meeting).
We will be meeting in #centos-devel on Freenode.
Agenda: #info Topic: Action items from previous meeting #info Topic: Status Updates #info Subtopic: GlusterFS #info Subtopic: OpenAFS #info Subtopic: Ceph #info Subtopic: SCST #info Open Floor
Thanks, Lala _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hello,
Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ?
Bart.
On 03/06/2015 08:55 AM, Lalatendu Mohanty wrote:
Rescheduling the meeting to next week as others might not have an opportunity to read the meeting reminder for today.
Thanks, Lala
On 03/06/2015 06:46 AM, Lalatendu Mohanty wrote:
Greetings All!
Time for another Storage SIG meeting [1] ( We are following a bi-weekly schedule) . But I forgot to announce it yesterday. Sorry for the inconvenience caused. Let me know if it is too late to announce the meeting (in that case we can cancel this meeting).
We will be meeting in #centos-devel on Freenode.
Agenda: #info Topic: Action items from previous meeting #info Topic: Status Updates #info Subtopic: GlusterFS #info Subtopic: OpenAFS #info Subtopic: Ceph #info Subtopic: SCST #info Open Floor
Thanks, Lala _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 10 Mar 2015, at 11:09, Bart Van Assche bart.vanassche@sandisk.com wrote:
Hello,
Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ?
The "take a risk X might break" bit doesn't really sound suitable for the CentOS audience.
That being said... how often does the RDMA ABI change? If it's once every X years, then it might be live-able (with sufficient catches/warning so users aren't affected).
+ Justin
-- GlusterFS - http://www.gluster.org
An open source, distributed file system scaling to several petabytes, and handling thousands of clients.
My personal twitter: twitter.com/realjustinclift
On 03/11/15 18:01, Justin Clift wrote:
On 10 Mar 2015, at 11:09, Bart Van Assche bart.vanassche@sandisk.com wrote:
Hello,
Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ?
The "take a risk X might break" bit doesn't really sound suitable for the CentOS audience.
That being said... how often does the RDMA ABI change? If it's once every X years, then it might be live-able (with sufficient catches/warning so users aren't affected).
(back from traveling - sorry for the delay in replying)
Hello Justin,
So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ...
Bart.
On 18 Apr 2015, at 10:39, Bart Van Assche bart.vanassche@sandisk.com wrote:
On 03/11/15 18:01, Justin Clift wrote:
On 10 Mar 2015, at 11:09, Bart Van Assche bart.vanassche@sandisk.com wrote:
Hello,
Sorry but I will not be able to attend this meeting because at that time I will be on a plane. But I have been thinking further about how to provide SCST RPMs for CentOS. How about using the approach documented on http://wiki.centos.org/HowTos/BuildingKernelModules (weak updates) and taking the risk that the IB drivers may break if an update introduces an RDMA ABI change ?
The "take a risk X might break" bit doesn't really sound suitable for the CentOS audience.
That being said... how often does the RDMA ABI change? If it's once every X years, then it might be live-able (with sufficient catches/warning so users aren't affected).
(back from traveling - sorry for the delay in replying)
Hello Justin,
So far I have only seen the RDMA ABI change between RHEL releases (e.g. from 7.0 to 7.1) but not yet due to a kernel update. Which of course is no guarantee that a change of the RDMA API will never happen in the future between kernel releases ...
Hmmmm... in general RHEL has an attitude of "don't change ABI in updates", but RDMA may or may not have different assumptions. I have no idea. ;)
Doug (just added to this email chain) likely knows though.
Doug?
+ Justin
-- GlusterFS - http://www.gluster.org
An open source, distributed file system scaling to several petabytes, and handling thousands of clients.
My personal twitter: twitter.com/realjustinclift