Hi Ben, Thanks for the update.
On Friday 15 July 2011 16:32:41 Ben Hutchings wrote: > No news. The question remains, what the cost may be to other NFS users. > Certainly NFS v4.1 is not a minor change, and it adds a lot of new code > to the nfs module. I guess the question is how do we go forward here? If the stumbling block is the fear of breaking something, how do we assess the risk involved against the potential benefits? One way would be to simply test it: just roll out an updated kernel to sid. This would allow people to complain if it breaks NFS support (if the code is broken then it needs to be fixed and the sooner the better). Perhaps another approach would be to provide an additional kernel package with NFS v4.1 support built-in and ask for feedback from people (either directly or perhaps via popcon). If it helps, I can provide some tests against NFS v4.1 and NFS v4.0 servers. A third possibility would be to wait until other distros (e.g., RHEL) have enabled NFS v4.1 support and see if there is a corresponding increase in NFS support tickets. Do any of these approaches make sense? Do you have an alternative way of assessing the risk? > I had a look at what RH is doing with this and noticed that in RHEL 6 > they only enabled it for x86_64. This does suggest that it may be too > expensive for smaller systems, but maybe it's just a random choice. It could be that, due to the high availability of x86_64-based machines, it's this platform that's been most tested during the NFS Connectathon events .. or, as you say, it might just be a random choice :-) Cheers, Paul. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201107181709.30907.paul.mil...@desy.de
