On Tue, May 5, 2015 at 2:07 PM, Johnny Hughes johnny@centos.org wrote:
WRT a new kernel .. the 3.18.x kernel has been selected to be maintained as an LTS until Jan 2017. I think we should start work on rebuilding this kernel and using it in the x4c projects.
https://lwn.net/Articles/636289/
Thoughts?
I will grab this kernel and try to roll in all the patches, etc. and see if I can make it work.
I did a little bit of work on building the 3.18 kernel a couple of weeks ago, but it looks like the blktap2.5 kernel code we were using before has totally bitrotted.
I see three ways forward:
1. Try to do a "deep port" of the functionality, continuing to maintain it going forward.
2. Start using the blktap3 code, which requires no kernel driver.
3. Drop blktap support, and ask people to use qdisk for vhd.
Re #1, I'm not really excited about the idea of trying to keep porting those patches forward (and finding and fixing bugs in the forward-port each time).
Re #2, this would require getting the blktap3 stuff working upstream and then backporting it.
#3 would be by far the easiest.
In parallel to the Xen for C7 work I've been doing, I've been working on getting upstream Xen to build against XenServer's blktap code, with then aim of moving to blktap3. If we want to go with #2, then a major kernel update will have to wait until that work is done.
-George
Hello,
On Wed, May 06, 2015 at 03:27:54PM +0100, George Dunlap wrote:
On Tue, May 5, 2015 at 2:07 PM, Johnny Hughes johnny@centos.org wrote:
WRT a new kernel .. the 3.18.x kernel has been selected to be maintained as an LTS until Jan 2017. I think we should start work on rebuilding this kernel and using it in the x4c projects.
https://lwn.net/Articles/636289/
Thoughts?
I will grab this kernel and try to roll in all the patches, etc. and see if I can make it work.
I did a little bit of work on building the 3.18 kernel a couple of weeks ago, but it looks like the blktap2.5 kernel code we were using before has totally bitrotted.
I see three ways forward:
- Try to do a "deep port" of the functionality, continuing to
maintain it going forward.
How badly has the blktap 2.5 kernel code bitrotted? What areas are the most problematic? Any idea how much work would it be to get it working with 3.18 LTS ?
Start using the blktap3 code, which requires no kernel driver.
Drop blktap support, and ask people to use qdisk for vhd.
Re #1, I'm not really excited about the idea of trying to keep porting those patches forward (and finding and fixing bugs in the forward-port each time).
Re #2, this would require getting the blktap3 stuff working upstream and then backporting it.
Yeah.. likely more work than the "deep port" of blktap 2.5 kernel code..
#3 would be by far the easiest.
But not very nice..
In parallel to the Xen for C7 work I've been doing, I've been working on getting upstream Xen to build against XenServer's blktap code, with then aim of moving to blktap3. If we want to go with #2, then a major kernel update will have to wait until that work is done.
-George
Thanks,
-- Pasi
On 05/06/2015 09:27 AM, George Dunlap wrote:
On Tue, May 5, 2015 at 2:07 PM, Johnny Hughes johnny@centos.org wrote:
WRT a new kernel .. the 3.18.x kernel has been selected to be maintained as an LTS until Jan 2017. I think we should start work on rebuilding this kernel and using it in the x4c projects.
https://lwn.net/Articles/636289/
Thoughts?
I will grab this kernel and try to roll in all the patches, etc. and see if I can make it work.
I did a little bit of work on building the 3.18 kernel a couple of weeks ago, but it looks like the blktap2.5 kernel code we were using before has totally bitrotted.
I see three ways forward:
- Try to do a "deep port" of the functionality, continuing to
maintain it going forward.
I did this with the kernel I released .. the blktap module is loaded upon boot.. I did have to change some of the code based on this Debain bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748953
I have no idea how well this works .. we could use some testing of that kernel here:
http://people.centos.org/hughesjr/xen-kernel/
Start using the blktap3 code, which requires no kernel driver.
Drop blktap support, and ask people to use qdisk for vhd.
Re #1, I'm not really excited about the idea of trying to keep porting those patches forward (and finding and fixing bugs in the forward-port each time).
This has not been a huge problem in the past .. it mostly works OK. At least no one has complained. The only time I had to change it was when we moved from 3.6 to 3.10 and then from 3.10 to 3.18. But that does not mean it works without issue, just that no one complained about it.
Re #2, this would require getting the blktap3 stuff working upstream and then backporting it.
#3 would be by far the easiest.
In parallel to the Xen for C7 work I've been doing, I've been working on getting upstream Xen to build against XenServer's blktap code, with then aim of moving to blktap3. If we want to go with #2, then a major kernel update will have to wait until that work is done.
I have no real preference .. just that we need a kernel update in 3 months as in Sept 2015, 3.10 support stops at kernel.org.
We can use the 3.18 LTS tree with my mods now, if it works for everyone .. although the best way longterm seems to be to use blktap3 in the future since that is what is in XenServer.
Thanks, Johnny hughes
On Fri, May 8, 2015 at 11:10 PM, Johnny Hughes johnny@centos.org wrote:
On 05/06/2015 09:27 AM, George Dunlap wrote:
On Tue, May 5, 2015 at 2:07 PM, Johnny Hughes johnny@centos.org wrote:
WRT a new kernel .. the 3.18.x kernel has been selected to be maintained as an LTS until Jan 2017. I think we should start work on rebuilding this kernel and using it in the x4c projects.
https://lwn.net/Articles/636289/
Thoughts?
I will grab this kernel and try to roll in all the patches, etc. and see if I can make it work.
I did a little bit of work on building the 3.18 kernel a couple of weeks ago, but it looks like the blktap2.5 kernel code we were using before has totally bitrotted.
I see three ways forward:
- Try to do a "deep port" of the functionality, continuing to
maintain it going forward.
I did this with the kernel I released .. the blktap module is loaded upon boot.. I did have to change some of the code based on this Debain bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748953
I have no idea how well this works .. we could use some testing of that kernel here:
Right -- done by none other than Citrix's own Bob Ball... who updated it in his own github branch but then forgot to send a pull request to to the main XenServer repo, which is why I didn't see it. :-)
Start using the blktap3 code, which requires no kernel driver.
Drop blktap support, and ask people to use qdisk for vhd.
Re #1, I'm not really excited about the idea of trying to keep porting those patches forward (and finding and fixing bugs in the forward-port each time).
This has not been a huge problem in the past .. it mostly works OK. At least no one has complained. The only time I had to change it was when we moved from 3.6 to 3.10 and then from 3.10 to 3.18. But that does not mean it works without issue, just that no one complained about it.
Right... well I guess there are other users of the same code (which is why Bob submitted the fix last year), so we can hope that it's at least getting a little testing. If we give it a month of beta testing before releasing it, I think that's the best people can expect from a community-run project.
In parallel to the Xen for C7 work I've been doing, I've been working on getting upstream Xen to build against XenServer's blktap code, with then aim of moving to blktap3. If we want to go with #2, then a major kernel update will have to wait until that work is done.
I have no real preference .. just that we need a kernel update in 3 months as in Sept 2015, 3.10 support stops at kernel.org.
We can use the 3.18 LTS tree with my mods now, if it works for everyone .. although the best way longterm seems to be to use blktap3 in the future since that is what is in XenServer.
Yes, using the forward-ported kernel blktap driver is probably the best thing to do until we have a replacement.
-George
-
George Dunlap -
Johnny Hughes -
Pasi Kärkkäinen