Hello - One of my users would like a kernel parameter changed. We're running CentOS 4.2 so I'm not sure if we need to upgrade the kernel for this change or not. He's seen that in the 2.6.11.12 kernel "PIPE_SIZE is defined in include/linux/pipe_fs_i.h and takes on the value of PAGE_SIZE" He wants PIPE_SIZE to be increased to 8*PAGE_SIZE. Can this be changed in the 2.6.9 kernel? If so, where would this be changed? If not, what kernel would be suggested for an upgrade (we have some experience with FC3 & the 2.6.11 kernel already)? Last, in your opinion does changing the kernel rev greatly change the name of what you're running? If we go to say the 2.6.16 kernel on our CentOS 4.2 system, is it still valid to call it CentOS 4.2? Thanks for any assistance, Debbie -- | Debbie Tropiano | debbiet at arlut.utexas.edu | | Environmental Sciences Laboratory | +1 512 835 3367 w | | Applied Research Laboratories of UT Austin | +1 512 835 3544 fax | | P.O. Box 8029, Austin, TX 78713-8029 | home email: debbie at icus.com |
On Tue, 2006-10-17 at 14:50 -0500, Debbie Tropiano wrote:> Hello - > > One of my users would like a kernel parameter changed. We're running > CentOS 4.2 so I'm not sure if we need to upgrade the kernel for this > change or not. He's seen that in the 2.6.11.12 kernel "PIPE_SIZE is > defined in include/linux/pipe_fs_i.h and takes on the value of PAGE_SIZE" > He wants PIPE_SIZE to be increased to 8*PAGE_SIZE.> Can this be changed in the 2.6.9 kernel? If so, where would this be changed? >I am not sure if that file is in 2.6.9 or not, but you can install the kernel SRPM and do extract (go to the SPECS dir and do rpmbuild -bp kernel-2.6.spec) you will have a full kernel tree in the BUILD directory.> If not, what kernel would be suggested for an upgrade (we have some experience > with FC3 & the 2.6.11 kernel already)? > > Last, in your opinion does changing the kernel rev greatly change the name > of what you're running? If we go to say the 2.6.16 kernel on our CentOS 4.2 > system, is it still valid to call it CentOS 4.2?If you are using it internally, sure. If you are distributing it ... not really :) Keep in mind that the kernel is not on an island and things like GLIBC are affected by the kernel and it's capabilities. Also, be aware that many things are compiled against the kernel headers some items can cause issues. These are mostly minimal, however it is possible that some programs will not function properly, especially things like selinux and auditing. Also, certain options are required for the extended ext3 functionality, etc. Personally, I think that the RedHat guys are very smart wrt to the kernel and I think the kernel is the most important part of the distro. So, other than building other modules or changing options in the config file (like we do with the centosplus kernel), I would normally use (and recommend) what they produce. That is not to say that other kernels, properly configured, could not perform better ... I would just not do it unless it was absolutely the only option. Thanks, Johnny Hughes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20061019/bce8b682/attachment-0002.sig>
<snip>> Personally, I think that the RedHat guys are very smart wrt to the > kernel and I think the kernel is the most important part of the distro. > So, other than building other modules or changing options in the config > file (like we do with the centosplus kernel), I would normally use (and > recommend) what they produce. > > That is not to say that other kernels, properly configured, could not > perform better ... I would just not do it unless it was absolutely the > only option. >Also, even if you have no other option, you should attempt to understand the ramifcations of the change you are making in the kernel. It will be no ones fault but yours if some piece of software needed to be rebuilt with the changed header, but wasn't and now does not work. And this brings you to the next point which is now you have your new shiny one-off kernel, when you find problems who do you go to. Well, from experience you end up have a system running without the one-off kernel, where you go to reproduce kernel problems so that you can seek assistence up stream (unless the problem turns out to only show up with your one off). If the problem turns out to only be with your one off kernel, then you can still ask questions, but your universe of people able to provide support has greatly diminished. As an aside, at one point RedHat in their RHCE classes actually taught their RHCE's to recompile the kernel to optimize it for what ever system they RHCE would work on. They don't do that anymore, and as a matter of fact if you recompile, officially they will not support you. I suspect something happened multiple times to cause this behavior, and I suspect it was various users thinking that they could make tweaks to the kernel not thinking these change through, and still get the same level of support. I don't really know though, but the fact remains if you recompile your kernel today their interest in supporting you is zero. Cheers...james