As I see it, the next step to seamlessly move to V4 as
the default is to make 'mount -o nfsvers=4' actually
do a v4 mount...
There are two obvious place we can make this change.
In the kernel and/or in the mount command...
Looking at the kernel, since v3 and v4 truly two different
file systems its seems a bit late for the nfs_get_sb()
to all of sudden have to change file system type. Meaning
when nfs_get_sb() sees the "nfsvers=4" somehow it would
have to back out and call nfs4_get_sb(), which obviously
is a bit hacky....
Now I guess we could have one nfs_get_sb() for both v3 and v4.
Where the nfs_get_sb() could peek into the options data to
see which version is needed. This would also mean the mount
command would always have to set a version so when the "nfsvers="
options is not set, the kernel would know which version to use.
Again, this feels a bit hacky as well but doable...
At least to me, what seems like the best option is to have
the mount.nfs binary early on intercept "nfsvers=4" option
and then change the fs_type to "nfs4", which would allow
everything to "trickle down" as it does today... Again to
me, that seem like the least intrusive way to do it...
Comments? Is there other ways?
steved.
> -----Original Message-----
> From: Steve Dickson [mailto:[email protected]]
> Sent: Thursday, March 19, 2009 9:18 AM
> To: linux NFS Mailing list
> Subject: The next step: nfsvers=4
>
> As I see it, the next step to seamlessly move to V4 as the
> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>
> There are two obvious place we can make this change.
> In the kernel and/or in the mount command...
>
> Looking at the kernel, since v3 and v4 truly two different
> file systems its seems a bit late for the nfs_get_sb() to all
> of sudden have to change file system type. Meaning when
> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>
> Now I guess we could have one nfs_get_sb() for both v3 and v4.
> Where the nfs_get_sb() could peek into the options data to
> see which version is needed. This would also mean the mount
> command would always have to set a version so when the "nfsvers="
> options is not set, the kernel would know which version to use.
> Again, this feels a bit hacky as well but doable...
>
> At least to me, what seems like the best option is to have
> the mount.nfs binary early on intercept "nfsvers=4" option
> and then change the fs_type to "nfs4", which would allow
> everything to "trickle down" as it does today... Again to me,
> that seem like the least intrusive way to do it...
>
> Comments? Is there other ways?
Whichever way it's done, if v4 becomes the default, don't forget to also
make the default behavior be that the system will fall back and try a v3
mount if v4 isn't available. Otherwise you'll break a huge percentage
of your user base. Of course then you also have to deal with the
semantics of how to specifify "only v4" vs. "try v4 first and fall
back".
>
> steved.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-nfs" in the body of a message to
> [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
On Mar 19, 2009, at Mar 19, 2009, 12:34 PM, Muntz, Daniel wrote:
>> -----Original Message-----
>> From: Steve Dickson [mailto:[email protected]]
>> Sent: Thursday, March 19, 2009 9:18 AM
>> To: linux NFS Mailing list
>> Subject: The next step: nfsvers=4
>>
>> As I see it, the next step to seamlessly move to V4 as the
>> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>>
>> There are two obvious place we can make this change.
>> In the kernel and/or in the mount command...
>>
>> Looking at the kernel, since v3 and v4 truly two different
>> file systems its seems a bit late for the nfs_get_sb() to all
>> of sudden have to change file system type. Meaning when
>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
>> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>>
>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>> Where the nfs_get_sb() could peek into the options data to
>> see which version is needed. This would also mean the mount
>> command would always have to set a version so when the "nfsvers="
>> options is not set, the kernel would know which version to use.
>> Again, this feels a bit hacky as well but doable...
>>
>> At least to me, what seems like the best option is to have
>> the mount.nfs binary early on intercept "nfsvers=4" option
>> and then change the fs_type to "nfs4", which would allow
>> everything to "trickle down" as it does today... Again to me,
>> that seem like the least intrusive way to do it...
>>
>> Comments? Is there other ways?
Having the mount.nfs command translate sounds like a pretty easy thing
to prototype.
> Whichever way it's done, if v4 becomes the default, don't forget to
> also
> make the default behavior be that the system will fall back and try
> a v3
> mount if v4 isn't available. Otherwise you'll break a huge percentage
> of your user base. Of course then you also have to deal with the
> semantics of how to specifify "only v4" vs. "try v4 first and fall
> back".
Today, specifying vers=3 means "I want vers=3 or nothing". Not
specifying any version means the mount command can choose which
version to use based on what both sides support.
If no vers= option is specified, I don't think it would be difficult
for the text-based mount command to try a "nfs4" mount first, and if
that fails try an "nfs" mount.
Steve, would you like me to provide a prototype mount.nfs command that
handles this?
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Muntz, Daniel wrote:
>
>
>> -----Original Message-----
>> From: Steve Dickson [mailto:[email protected]]
>> Sent: Thursday, March 19, 2009 9:18 AM
>> To: linux NFS Mailing list
>> Subject: The next step: nfsvers=4
>>
>> As I see it, the next step to seamlessly move to V4 as the
>> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>>
>> There are two obvious place we can make this change.
>> In the kernel and/or in the mount command...
>>
>> Looking at the kernel, since v3 and v4 truly two different
>> file systems its seems a bit late for the nfs_get_sb() to all
>> of sudden have to change file system type. Meaning when
>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
>> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>>
>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>> Where the nfs_get_sb() could peek into the options data to
>> see which version is needed. This would also mean the mount
>> command would always have to set a version so when the "nfsvers="
>> options is not set, the kernel would know which version to use.
>> Again, this feels a bit hacky as well but doable...
>>
>> At least to me, what seems like the best option is to have
>> the mount.nfs binary early on intercept "nfsvers=4" option
>> and then change the fs_type to "nfs4", which would allow
>> everything to "trickle down" as it does today... Again to me,
>> that seem like the least intrusive way to do it...
>>
>> Comments? Is there other ways?
>
> Whichever way it's done, if v4 becomes the default, don't forget to also
> make the default behavior be that the system will fall back and try a v3
> mount if v4 isn't available. Otherwise you'll break a huge percentage
> of your user base. Of course then you also have to deal with the
> semantics of how to specifify "only v4" vs. "try v4 first and fall
> back".
No worries... falling back to v3/v2 will be the will definitely
happen before the switch is made...
This was this is reason I'm pushing for a mount configuration file.
So the semantics of which version is or is not tried can be defined locally...
steved.
Chuck Lever wrote:
> On Mar 19, 2009, at Mar 19, 2009, 12:34 PM, Muntz, Daniel wrote:
>>> -----Original Message-----
>>> From: Steve Dickson [mailto:[email protected]]
>>> Sent: Thursday, March 19, 2009 9:18 AM
>>> To: linux NFS Mailing list
>>> Subject: The next step: nfsvers=4
>>>
>>> As I see it, the next step to seamlessly move to V4 as the
>>> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>>>
>>> There are two obvious place we can make this change.
>>> In the kernel and/or in the mount command...
>>>
>>> Looking at the kernel, since v3 and v4 truly two different
>>> file systems its seems a bit late for the nfs_get_sb() to all
>>> of sudden have to change file system type. Meaning when
>>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
>>> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>>>
>>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>>> Where the nfs_get_sb() could peek into the options data to
>>> see which version is needed. This would also mean the mount
>>> command would always have to set a version so when the "nfsvers="
>>> options is not set, the kernel would know which version to use.
>>> Again, this feels a bit hacky as well but doable...
>>>
>>> At least to me, what seems like the best option is to have
>>> the mount.nfs binary early on intercept "nfsvers=4" option
>>> and then change the fs_type to "nfs4", which would allow
>>> everything to "trickle down" as it does today... Again to me,
>>> that seem like the least intrusive way to do it...
>>>
>>> Comments? Is there other ways?
>
> Having the mount.nfs command translate sounds like a pretty easy thing
> to prototype.
Yes.. I agree...
>
>> Whichever way it's done, if v4 becomes the default, don't forget to also
>> make the default behavior be that the system will fall back and try a v3
>> mount if v4 isn't available. Otherwise you'll break a huge percentage
>> of your user base. Of course then you also have to deal with the
>> semantics of how to specifify "only v4" vs. "try v4 first and fall
>> back".
>
> Today, specifying vers=3 means "I want vers=3 or nothing". Not
> specifying any version means the mount command can choose which version
> to use based on what both sides support.
>
> If no vers= option is specified, I don't think it would be difficult for
> the text-based mount command to try a "nfs4" mount first, and if that
> fails try an "nfs" mount.
>
> Steve, would you like me to provide a prototype mount.nfs command that
> handles this?
Well I was thinking more of lets walk before we run... meaning... lets just get the
'nfsvers=4' working and accepted. Then deal with the v4/v3/v2 fall back in the
next patch set...
As you say... the prototype looks to be pretty easy... so let me take a crack at
it... besides... you are making some good progress with IPV6 code... I don't
think this should get in the way of that...
steved.
steved.
On Mar. 19, 2009, 18:43 +0200, Chuck Lever <[email protected]> wrote:
> On Mar 19, 2009, at Mar 19, 2009, 12:34 PM, Muntz, Daniel wrote:
>>> -----Original Message-----
>>> From: Steve Dickson [mailto:[email protected]]
>>> Sent: Thursday, March 19, 2009 9:18 AM
>>> To: linux NFS Mailing list
>>> Subject: The next step: nfsvers=4
>>>
>>> As I see it, the next step to seamlessly move to V4 as the
>>> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>>>
>>> There are two obvious place we can make this change.
>>> In the kernel and/or in the mount command...
>>>
>>> Looking at the kernel, since v3 and v4 truly two different
>>> file systems its seems a bit late for the nfs_get_sb() to all
>>> of sudden have to change file system type. Meaning when
>>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
>>> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>>>
>>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>>> Where the nfs_get_sb() could peek into the options data to
>>> see which version is needed. This would also mean the mount
>>> command would always have to set a version so when the "nfsvers="
>>> options is not set, the kernel would know which version to use.
>>> Again, this feels a bit hacky as well but doable...
>>>
>>> At least to me, what seems like the best option is to have
>>> the mount.nfs binary early on intercept "nfsvers=4" option
>>> and then change the fs_type to "nfs4", which would allow
>>> everything to "trickle down" as it does today... Again to me,
>>> that seem like the least intrusive way to do it...
>>>
>>> Comments? Is there other ways?
>
> Having the mount.nfs command translate sounds like a pretty easy thing
> to prototype.
>
>> Whichever way it's done, if v4 becomes the default, don't forget to
>> also
>> make the default behavior be that the system will fall back and try
>> a v3
>> mount if v4 isn't available. Otherwise you'll break a huge percentage
>> of your user base. Of course then you also have to deal with the
>> semantics of how to specifify "only v4" vs. "try v4 first and fall
>> back".
>
> Today, specifying vers=3 means "I want vers=3 or nothing". Not
> specifying any version means the mount command can choose which
> version to use based on what both sides support.
>
> If no vers= option is specified, I don't think it would be difficult
> for the text-based mount command to try a "nfs4" mount first, and if
> that fails try an "nfs" mount.
Agreed.
That's pretty much what we planned to do in the future also
for minorversion=1, after discussing this also with Trond.
The principle was that the policy for choosing what versions
to try and in which order should be determined by the
user mode utilities since one can think of customers that would
only want to use nfsv4.1 for its exactly once semantics,
or others that would want to start with 4.0 and fall back
to 3 and 2 since trying 4.1 might break their servers, etc.
I think that if no version is specified all versions that
the client supports should be tried, highest first.
Otherwise mount.nfs should try only the specified version.
For implementing more complex policies, maybe we can extend
the command syntax to accept a range and/or an ordered list
of versions to try.
Benny
>
> Steve, would you like me to provide a prototype mount.nfs command that
> handles this?
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mar 19, 2009, at Mar 19, 2009, 1:33 PM, Benny Halevy wrote:
> On Mar. 19, 2009, 18:43 +0200, Chuck Lever <[email protected]>
> wrote:
>> On Mar 19, 2009, at Mar 19, 2009, 12:34 PM, Muntz, Daniel wrote:
>>>> -----Original Message-----
>>>> From: Steve Dickson [mailto:[email protected]]
>>>> Sent: Thursday, March 19, 2009 9:18 AM
>>>> To: linux NFS Mailing list
>>>> Subject: The next step: nfsvers=4
>>>>
>>>> As I see it, the next step to seamlessly move to V4 as the
>>>> default is to make 'mount -o nfsvers=4' actually do a v4 mount...
>>>>
>>>> There are two obvious place we can make this change.
>>>> In the kernel and/or in the mount command...
>>>>
>>>> Looking at the kernel, since v3 and v4 truly two different
>>>> file systems its seems a bit late for the nfs_get_sb() to all
>>>> of sudden have to change file system type. Meaning when
>>>> nfs_get_sb() sees the "nfsvers=4" somehow it would have to
>>>> back out and call nfs4_get_sb(), which obviously is a bit hacky....
>>>>
>>>> Now I guess we could have one nfs_get_sb() for both v3 and v4.
>>>> Where the nfs_get_sb() could peek into the options data to
>>>> see which version is needed. This would also mean the mount
>>>> command would always have to set a version so when the "nfsvers="
>>>> options is not set, the kernel would know which version to use.
>>>> Again, this feels a bit hacky as well but doable...
>>>>
>>>> At least to me, what seems like the best option is to have
>>>> the mount.nfs binary early on intercept "nfsvers=4" option
>>>> and then change the fs_type to "nfs4", which would allow
>>>> everything to "trickle down" as it does today... Again to me,
>>>> that seem like the least intrusive way to do it...
>>>>
>>>> Comments? Is there other ways?
>>
>> Having the mount.nfs command translate sounds like a pretty easy
>> thing
>> to prototype.
>>
>>> Whichever way it's done, if v4 becomes the default, don't forget to
>>> also
>>> make the default behavior be that the system will fall back and try
>>> a v3
>>> mount if v4 isn't available. Otherwise you'll break a huge
>>> percentage
>>> of your user base. Of course then you also have to deal with the
>>> semantics of how to specifify "only v4" vs. "try v4 first and fall
>>> back".
>>
>> Today, specifying vers=3 means "I want vers=3 or nothing". Not
>> specifying any version means the mount command can choose which
>> version to use based on what both sides support.
>>
>> If no vers= option is specified, I don't think it would be difficult
>> for the text-based mount command to try a "nfs4" mount first, and if
>> that fails try an "nfs" mount.
>
> Agreed.
> That's pretty much what we planned to do in the future also
> for minorversion=1, after discussing this also with Trond.
> The principle was that the policy for choosing what versions
> to try and in which order should be determined by the
> user mode utilities since one can think of customers that would
> only want to use nfsv4.1 for its exactly once semantics,
> or others that would want to start with 4.0 and fall back
> to 3 and 2 since trying 4.1 might break their servers, etc.
>
> I think that if no version is specified all versions that
> the client supports should be tried, highest first.
> Otherwise mount.nfs should try only the specified version.
One nit is that the set of mount options supported by nfs4 is
different than the set supported by nfs. clientaddr= is supported by
nfs4, but not by nfs, for example. I believe that nocto is not
supported by nfs4. The mountproto option is only supported by nfs.
If no vers= is specified and only NFSv4 is available on the server,
but something like "nocto" shows up on the command line mount options,
do we:
a) fail the mount, or
b) ignore the nocto option
a) seems like the least surprising behavior.
What about "proto=udp" ? Linux supports UDP for NFSv4, though other
server implementations probably don't. If that's specified on a mount
command line without a vers= option, what version should we choose?
> For implementing more complex policies, maybe we can extend
> the command syntax to accept a range and/or an ordered list
> of versions to try.
Steve mentioned /etc/default/nfs on Solaris. I could see /etc/
sysconfig/nfs on Linux containing a couple of lines defining the range
of allowable NFS versions, if we think this is necessary. This is a
simple pre-existing file, and has little potential for introducing
negative side-effects.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
At 02:13 PM 3/19/2009, Chuck Lever wrote:
>On Mar 19, 2009, at Mar 19, 2009, 1:33 PM, Benny Halevy wrote:
>> I think that if no version is specified all versions that
>> the client supports should be tried, highest first.
>> Otherwise mount.nfs should try only the specified version.
>
>One nit is that the set of mount options supported by nfs4 is
>different than the set supported by nfs. clientaddr= is supported by
>nfs4, but not by nfs, for example. I believe that nocto is not
>supported by nfs4. The mountproto option is only supported by nfs.
>
>If no vers= is specified and only NFSv4 is available on the server,
>but something like "nocto" shows up on the command line mount options,
>do we:
>
>a) fail the mount, or
>b) ignore the nocto option
>
>a) seems like the least surprising behavior.
I think the "sloppy" option might be relevant here too.
While we're on the subject of sloppy, what about the automounter?
It has always been an issue to deploy automounter maps which are
shared by diverse client populations - there are significant issues
for older Linux clients, and newer Solaris ones for that matter, with
NFSv4.
I would strongly suggest touching and/or changing as few options as
possible, and paying close attention to the results with legacy or
generic configurations on new kernels. The more lenient, the better
IMO, except where specific options require specific actions.
Tom.
Chuck Lever wrote:
> If no vers= is specified and only NFSv4 is available on the server, but
> something like "nocto" shows up on the command line mount options, do we:
>
> a) fail the mount, or
> b) ignore the nocto option
I would say ignore this particular option... since, in a sense, v4 give you this option
by default due to delegations... but point well taken... The mapping of
v3 to v4 and visa versa will have to be addressed... I would guess in the mount
command...
>
> a) seems like the least surprising behavior.
>
> What about "proto=udp" ? Linux supports UDP for NFSv4, though other
> server implementations probably don't. If that's specified on a mount
> command line without a vers= option, what version should we choose?
I think people just want things to work... so if they specify only UDP
and the server supports V4, we give them V4/TCP. If they REALLY want
UDP, they would have to specify 'nfsvers=3,udp'.
Or, if there was an mount configuration file, they could specify the
MAX_VERSION to be 3 and then -o udp mounts work as expected...
>
>> For implementing more complex policies, maybe we can extend
>> the command syntax to accept a range and/or an ordered list
>> of versions to try.
>
> Steve mentioned /etc/default/nfs on Solaris. I could see
> /etc/sysconfig/nfs on Linux containing a couple of lines defining the
> range of allowable NFS versions, if we think this is necessary. This is
> a simple pre-existing file, and has little potential for introducing
> negative side-effects.
The /etc/sysconfig/nfs is a distro only file... Meaning I know of only
one distro that uses that file.. So I would tend to shy away from putting
anything in that...
steved.
Tom Talpey wrote:
> At 02:13 PM 3/19/2009, Chuck Lever wrote:
>> On Mar 19, 2009, at Mar 19, 2009, 1:33 PM, Benny Halevy wrote:
>>> I think that if no version is specified all versions that
>>> the client supports should be tried, highest first.
>>> Otherwise mount.nfs should try only the specified version.
>> One nit is that the set of mount options supported by nfs4 is
>> different than the set supported by nfs. clientaddr= is supported by
>> nfs4, but not by nfs, for example. I believe that nocto is not
>> supported by nfs4. The mountproto option is only supported by nfs.
>>
>> If no vers= is specified and only NFSv4 is available on the server,
>> but something like "nocto" shows up on the command line mount options,
>> do we:
>>
>> a) fail the mount, or
>> b) ignore the nocto option
>>
>> a) seems like the least surprising behavior.
>
> I think the "sloppy" option might be relevant here too.
>
> While we're on the subject of sloppy, what about the automounter?
> It has always been an issue to deploy automounter maps which are
> shared by diverse client populations - there are significant issues
> for older Linux clients, and newer Solaris ones for that matter, with
> NFSv4.
>
I ran into this very situation today which caused me to go back through
the archive and find this thread. Hopefully it isn't too late to add my
two cents.
I want to begin testing nfsv4 in our environment, we rely heavily on
autofs, and have a mixed OS environment, and some servers support v4,
while others don't.
Most clients should continue to mount with v3, while a few select test
machines should mount with v4 if the server supports it.
OSX and (i think) Solaris seem to use fstype=nfs and [nfs]vers=2,3,4 to
specify the nfs version. Linux on the other hand, requires that I set
fstype=nfs4, and will fail to mount if [nfs]vers is present.
If nfsvers was just ignored or better yet, was honored (if I set
fstype=nfs, and nfsvers=4, I don't really care that you change fstype to
nfs4 on me under the covers), it would eliminate one hurdle in the quest
for a unified automount map (at least in our environment).
-kevin
> I would strongly suggest touching and/or changing as few options as
> possible, and paying close attention to the results with legacy or
> generic configurations on new kernels. The more lenient, the better
> IMO, except where specific options require specific actions.
>
> Tom.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Steve Dickson wrote:
> Chuck Lever wrote:
>> If no vers= is specified and only NFSv4 is available on the server, but
>> something like "nocto" shows up on the command line mount options, do we:
>>
>> a) fail the mount, or
>> b) ignore the nocto option
> I would say ignore this particular option... since, in a sense, v4 give you this option
> by default due to delegations... but point well taken... The mapping of
> v3 to v4 and visa versa will have to be addressed... I would guess in the mount
> command...
>
>> a) seems like the least surprising behavior.
>>
>> What about "proto=udp" ? Linux supports UDP for NFSv4, though other
>> server implementations probably don't. If that's specified on a mount
>> command line without a vers= option, what version should we choose?
> I think people just want things to work... so if they specify only UDP
> and the server supports V4, we give them V4/TCP. If they REALLY want
> UDP, they would have to specify 'nfsvers=3,udp'.
>
> Or, if there was an mount configuration file, they could specify the
> MAX_VERSION to be 3 and then -o udp mounts work as expected...
>
I would agree that things should just work as much as possible. I would
think that the options that aren't applicable should be ignored, and the
values that are known to be incorrect should be fixed if possible.
More likely than not, I care that my mount succeeds. Once that happens,
I begin to care how it succeeded, and can go figure out where I made a
mistake and how I ended up with v4/tcp when I really wanted udp and
didn't care which nfs version I use.
>>> For implementing more complex policies, maybe we can extend
>>> the command syntax to accept a range and/or an ordered list
>>> of versions to try.
>> Steve mentioned /etc/default/nfs on Solaris. I could see
>> /etc/sysconfig/nfs on Linux containing a couple of lines defining the
>> range of allowable NFS versions, if we think this is necessary. This is
>> a simple pre-existing file, and has little potential for introducing
>> negative side-effects.
I like the idea of having a file that allows me to specify or default
values, or acceptable ranges for the various mount options. I'd also
like to be able to specify overrideable options in the automount maps
where the right-most option wins.
-kevin
> The /etc/sysconfig/nfs is a distro only file... Meaning I know of only
> one distro that uses that file.. So I would tend to shy away from putting
> anything in that...
>
> steved.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html