We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH
for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
Before, only a break in swich can not make the program out of for loop.
Signed-off-by: Yang Bai <[email protected]>
---
utils/mount/stropts.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
index 314a806..4032bf3 100644
--- a/utils/mount/stropts.c
+++ b/utils/mount/stropts.c
@@ -665,9 +665,10 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
case EHOSTUNREACH:
continue;
default:
- break;
+ goto out;
}
}
+out:
return ret;
}
@@ -751,9 +752,10 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
case EHOSTUNREACH:
continue;
default:
- break;
+ goto out;
}
}
+out:
return ret;
}
--
1.7.1
Yeah... I believe its this one
https://bugzilla.redhat.com/show_bug.cgi?id=744657
On 10/13/2011 10:53 AM, Chuck Lever wrote:
> What was the presenting problem? Is there a bugzilla report I can look at?
>
> On Oct 11, 2011, at 5:44 AM, Hamo wrote:
>
>> We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH
>> for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
>> Before, only a break in swich can not make the program out of for loop.
>>
>> Signed-off-by: Yang Bai <[email protected]>
>> ---
>> utils/mount/stropts.c | 6 ++++--
>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
>> index 314a806..4032bf3 100644
>> --- a/utils/mount/stropts.c
>> +++ b/utils/mount/stropts.c
>> @@ -665,9 +665,10 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
>> case EHOSTUNREACH:
>> continue;
>> default:
>> - break;
>> + goto out;
>> }
>> }
>> +out:
>> return ret;
>> }
>>
>> @@ -751,9 +752,10 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
>> case EHOSTUNREACH:
>> continue;
>> default:
>> - break;
>> + goto out;
>> }
>> }
>> +out:
>> return ret;
>> }
>>
>> --
>> 1.7.1
>> --
>> 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
>
"You are not authorized to access bug #744657."
On Oct 13, 2011, at 12:34 PM, Steve Dickson wrote:
> Yeah... I believe its this one
> https://bugzilla.redhat.com/show_bug.cgi?id=744657
>
> On 10/13/2011 10:53 AM, Chuck Lever wrote:
>> What was the presenting problem? Is there a bugzilla report I can look at?
>>
>> On Oct 11, 2011, at 5:44 AM, Hamo wrote:
>>
>>> We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH
>>> for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
>>> Before, only a break in swich can not make the program out of for loop.
>>>
>>> Signed-off-by: Yang Bai <[email protected]>
>>> ---
>>> utils/mount/stropts.c | 6 ++++--
>>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
>>> index 314a806..4032bf3 100644
>>> --- a/utils/mount/stropts.c
>>> +++ b/utils/mount/stropts.c
>>> @@ -665,9 +665,10 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
>>> case EHOSTUNREACH:
>>> continue;
>>> default:
>>> - break;
>>> + goto out;
>>> }
>>> }
>>> +out:
>>> return ret;
>>> }
>>>
>>> @@ -751,9 +752,10 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
>>> case EHOSTUNREACH:
>>> continue;
>>> default:
>>> - break;
>>> + goto out;
>>> }
>>> }
>>> +out:
>>> return ret;
>>> }
>>>
>>> --
>>> 1.7.1
>>> --
>>> 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
>>
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On 10/15/2011 09:12 AM, Hamo wrote:
> [Copy from RedHat Bugzilla]
>
> The real problem is here:
>
> [root@dell-pe2950-01 ~]# mount -t nfs -v rhel6-nfs:/export/home /mnt/testdir
> mount.nfs: timeout set for Fri Oct 14 05:42:43 2011
> mount.nfs: trying text-based options
> 'vers=4,addr=fec0:0:a10:4000:221:5eff:fe95:20f4,clientaddr=fec0:0:a10:4000:213:72ff:fe62:469b'
> rhel6-nfs:/export/home on /mnt/testdir type nfs (rw)
>
>
> [root@dell-pe2950-01 ~]# mount -t nfs -v rhel6-nfs:/export/home /mnt/testdir
> mount.nfs: timeout set for Fri Oct 14 05:42:52 2011
> mount.nfs: trying text-based options
> 'vers=4,addr=fec0:0:a10:4000:221:5eff:fe95:20f4,clientaddr=fec0:0:a10:4000:213:72ff:fe62:469b'
> mount.nfs: mount(2): Device or resource busy
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> mount.nfs: trying text-based options
> 'vers=4,addr=10.16.64.25,clientaddr=10.16.64.133'
> rhel6-nfs:/export/home on /mnt/testdir type nfs (rw)
>
> mount has already found that this server has been mounted but also fallback to
> mount it using IPv4. This patch fix this problem.
Ah... I see... thanks...
steved.
>
>
> On Fri, Oct 14, 2011 at 3:03 AM, Steve Dickson <[email protected]> wrote:
>>
>>
>> On 10/13/2011 01:54 PM, Chuck Lever wrote:
>>>
>>> On Oct 13, 2011, at 12:59 PM, Steve Dickson wrote:
>>>
>>>> Looking further into this issue, I noticed all the following
>>>> mounts were successful.
>>>>
>>>> # mount -o v3 localhost:/home /mnt/home
>>>> # mount -o v4 localhost:/home /mnt/home
>>>
>>> Does this actually change the NFS version in use for /mnt/home, or does the client recognize that this is the same server and export as an existing mount point, and share the cache and mount options?
>> Using wireshark, I verified that the version does indeed change...
>>
>>>
>>> If the mount options are the same, this is equivalent to
>>>
>>> # mount -o v3 localhost:/home /mnt/home
>>> # mount -o v3 localhost:/home /mnt/home
>> In this case the second mount does fail with EBUSY..
>>
>> steved.
On 10/11/2011 05:44 AM, Hamo wrote:
> We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH
> for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
> Before, only a break in swich can not make the program out of for loop.
>
> Signed-off-by: Yang Bai <[email protected]>
Committed....
steved.
> ---
> utils/mount/stropts.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
> index 314a806..4032bf3 100644
> --- a/utils/mount/stropts.c
> +++ b/utils/mount/stropts.c
> @@ -665,9 +665,10 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
> case EHOSTUNREACH:
> continue;
> default:
> - break;
> + goto out;
> }
> }
> +out:
> return ret;
> }
>
> @@ -751,9 +752,10 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
> case EHOSTUNREACH:
> continue;
> default:
> - break;
> + goto out;
> }
> }
> +out:
> return ret;
> }
>
[Copy from RedHat Bugzilla]
The real problem is here:
[root@dell-pe2950-01 ~]# mount -t nfs -v rhel6-nfs:/export/home /mnt/testdir
mount.nfs: timeout set for Fri Oct 14 05:42:43 2011
mount.nfs: trying text-based options
'vers=4,addr=fec0:0:a10:4000:221:5eff:fe95:20f4,clientaddr=fec0:0:a10:4000:213:72ff:fe62:469b'
rhel6-nfs:/export/home on /mnt/testdir type nfs (rw)
[root@dell-pe2950-01 ~]# mount -t nfs -v rhel6-nfs:/export/home /mnt/testdir
mount.nfs: timeout set for Fri Oct 14 05:42:52 2011
mount.nfs: trying text-based options
'vers=4,addr=fec0:0:a10:4000:221:5eff:fe95:20f4,clientaddr=fec0:0:a10:4000:213:72ff:fe62:469b'
mount.nfs: mount(2): Device or resource busy
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
mount.nfs: trying text-based options
'vers=4,addr=10.16.64.25,clientaddr=10.16.64.133'
rhel6-nfs:/export/home on /mnt/testdir type nfs (rw)
mount has already found that this server has been mounted but also fallback to
mount it using IPv4. This patch fix this problem.
On Fri, Oct 14, 2011 at 3:03 AM, Steve Dickson <[email protected]> wrote:
>
>
> On 10/13/2011 01:54 PM, Chuck Lever wrote:
>>
>> On Oct 13, 2011, at 12:59 PM, Steve Dickson wrote:
>>
>>> Looking further into this issue, I noticed all the following
>>> mounts were successful.
>>>
>>> # mount -o v3 localhost:/home /mnt/home
>>> # mount -o v4 localhost:/home /mnt/home
>>
>> Does this actually change the NFS version in use for /mnt/home, or does the client recognize that this is the same server and export as an existing mount point, and share the cache and mount options?
> Using wireshark, I verified that the version does indeed change...
>
>>
>> If the mount options are the same, this is equivalent to
>>
>> # mount -o v3 localhost:/home /mnt/home
>> # mount -o v3 localhost:/home /mnt/home
> In this case the second mount does fail with EBUSY..
>
> steved.
On 10/13/2011 01:54 PM, Chuck Lever wrote:
>
> On Oct 13, 2011, at 12:59 PM, Steve Dickson wrote:
>
>> Looking further into this issue, I noticed all the following
>> mounts were successful.
>>
>> # mount -o v3 localhost:/home /mnt/home
>> # mount -o v4 localhost:/home /mnt/home
>
> Does this actually change the NFS version in use for /mnt/home, or does the client recognize that this is the same server and export as an existing mount point, and share the cache and mount options?
Using wireshark, I verified that the version does indeed change...
>
> If the mount options are the same, this is equivalent to
>
> # mount -o v3 localhost:/home /mnt/home
> # mount -o v3 localhost:/home /mnt/home
In this case the second mount does fail with EBUSY..
steved.
>
> And both mount requests should succeed.
>
>> # mount -o v4 [fec0::2:5652:ff:fe20:8459]:/home /mnt/home
>> # mount -o v3 [fec0::2:5652:ff:fe20:8459]:/home /mnt/home
>>
>> which the mount point, /mnt/home is mounted 4 different times
>> to the same server.
>
> Assuming localhost is fec0::2:5652:ff:fe20:8459, this test allows you to mount the same server by an IPv4 and an IPv6 address onto the same local directory. Why then does 744657's test case fail?
>
>> Is by design or a real problem?
>> steved.
>>
>>
>> On 10/13/2011 12:34 PM, Steve Dickson wrote:
>>> Yeah... I believe its this one
>>> https://bugzilla.redhat.com/show_bug.cgi?id=744657
>>>
>>> On 10/13/2011 10:53 AM, Chuck Lever wrote:
>>>> What was the presenting problem? Is there a bugzilla report I can look at?
>>>>
>>>> On Oct 11, 2011, at 5:44 AM, Hamo wrote:
>>>>
>>>>> We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH
>>>>> for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
>>>>> Before, only a break in swich can not make the program out of for loop.
>>>>>
>>>>> Signed-off-by: Yang Bai <[email protected]>
>>>>> ---
>>>>> utils/mount/stropts.c | 6 ++++--
>>>>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
>>>>> index 314a806..4032bf3 100644
>>>>> --- a/utils/mount/stropts.c
>>>>> +++ b/utils/mount/stropts.c
>>>>> @@ -665,9 +665,10 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
>>>>> case EHOSTUNREACH:
>>>>> continue;
>>>>> default:
>>>>> - break;
>>>>> + goto out;
>>>>> }
>>>>> }
>>>>> +out:
>>>>> return ret;
>>>>> }
>>>>>
>>>>> @@ -751,9 +752,10 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
>>>>> case EHOSTUNREACH:
>>>>> continue;
>>>>> default:
>>>>> - break;
>>>>> + goto out;
>>>>> }
>>>>> }
>>>>> +out:
>>>>> return ret;
>>>>> }
>>>>>
>>>>> --
>>>>> 1.7.1
>>>>> --
>>>>> 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
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>
This is by design.
NFSv3 and NFSv4 have no server-side identifiers to inform us that we may
be talking to the same server, and so we don't worry about doing so.
An NFSv4.1 server can tell you that this is the same server replying on
different IP addresses. We are planning on adding proper support for
that, but I don't believe we've currently got it right.
Cheers
Trond
On Thu, 2011-10-13 at 12:59 -0400, Steve Dickson wrote:
> Looking further into this issue, I noticed all the following
> mounts were successful.
>
> # mount -o v3 localhost:/home /mnt/home
> # mount -o v4 localhost:/home /mnt/home
> # mount -o v4 [fec0::2:5652:ff:fe20:8459]:/home /mnt/home
> # mount -o v3 [fec0::2:5652:ff:fe20:8459]:/home /mnt/home
>
> which the mount point, /mnt/home is mounted 4 different times
> to the same server.
>
> Is by design or a real problem?
>
> steved.
>
>
> On 10/13/2011 12:34 PM, Steve Dickson wrote:
> > Yeah... I believe its this one
> > https://bugzilla.redhat.com/show_bug.cgi?id=744657
> >
> > On 10/13/2011 10:53 AM, Chuck Lever wrote:
> >> What was the presenting problem? Is there a bugzilla report I can look at?
> >>
> >> On Oct 11, 2011, at 5:44 AM, Hamo wrote:
> >>
> >>> We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH
> >>> for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
> >>> Before, only a break in swich can not make the program out of for loop.
> >>>
> >>> Signed-off-by: Yang Bai <[email protected]>
> >>> ---
> >>> utils/mount/stropts.c | 6 ++++--
> >>> 1 files changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
> >>> index 314a806..4032bf3 100644
> >>> --- a/utils/mount/stropts.c
> >>> +++ b/utils/mount/stropts.c
> >>> @@ -665,9 +665,10 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
> >>> case EHOSTUNREACH:
> >>> continue;
> >>> default:
> >>> - break;
> >>> + goto out;
> >>> }
> >>> }
> >>> +out:
> >>> return ret;
> >>> }
> >>>
> >>> @@ -751,9 +752,10 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
> >>> case EHOSTUNREACH:
> >>> continue;
> >>> default:
> >>> - break;
> >>> + goto out;
> >>> }
> >>> }
> >>> +out:
> >>> return ret;
> >>> }
> >>>
> >>> --
> >>> 1.7.1
> >>> --
> >>> 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
> >>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> --
> 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
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Oct 13, 2011, at 12:59 PM, Steve Dickson wrote:
> Looking further into this issue, I noticed all the following
> mounts were successful.
>
> # mount -o v3 localhost:/home /mnt/home
> # mount -o v4 localhost:/home /mnt/home
Does this actually change the NFS version in use for /mnt/home, or does the client recognize that this is the same server and export as an existing mount point, and share the cache and mount options?
If the mount options are the same, this is equivalent to
# mount -o v3 localhost:/home /mnt/home
# mount -o v3 localhost:/home /mnt/home
And both mount requests should succeed.
> # mount -o v4 [fec0::2:5652:ff:fe20:8459]:/home /mnt/home
> # mount -o v3 [fec0::2:5652:ff:fe20:8459]:/home /mnt/home
>
> which the mount point, /mnt/home is mounted 4 different times
> to the same server.
Assuming localhost is fec0::2:5652:ff:fe20:8459, this test allows you to mount the same server by an IPv4 and an IPv6 address onto the same local directory. Why then does 744657's test case fail?
> Is by design or a real problem?
> steved.
>
>
> On 10/13/2011 12:34 PM, Steve Dickson wrote:
>> Yeah... I believe its this one
>> https://bugzilla.redhat.com/show_bug.cgi?id=744657
>>
>> On 10/13/2011 10:53 AM, Chuck Lever wrote:
>>> What was the presenting problem? Is there a bugzilla report I can look at?
>>>
>>> On Oct 11, 2011, at 5:44 AM, Hamo wrote:
>>>
>>>> We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH
>>>> for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
>>>> Before, only a break in swich can not make the program out of for loop.
>>>>
>>>> Signed-off-by: Yang Bai <[email protected]>
>>>> ---
>>>> utils/mount/stropts.c | 6 ++++--
>>>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
>>>> index 314a806..4032bf3 100644
>>>> --- a/utils/mount/stropts.c
>>>> +++ b/utils/mount/stropts.c
>>>> @@ -665,9 +665,10 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
>>>> case EHOSTUNREACH:
>>>> continue;
>>>> default:
>>>> - break;
>>>> + goto out;
>>>> }
>>>> }
>>>> +out:
>>>> return ret;
>>>> }
>>>>
>>>> @@ -751,9 +752,10 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
>>>> case EHOSTUNREACH:
>>>> continue;
>>>> default:
>>>> - break;
>>>> + goto out;
>>>> }
>>>> }
>>>> +out:
>>>> return ret;
>>>> }
>>>>
>>>> --
>>>> 1.7.1
>>>> --
>>>> 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
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
CC: Chuck Lever <[email protected]>
On Tue, Oct 11, 2011 at 5:44 PM, Hamo <[email protected]> wrote:
> We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH
> for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
> Before, only a break in swich can not make the program out of for loop.
>
> Signed-off-by: Yang Bai <[email protected]>
> ---
> utils/mount/stropts.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
> index 314a806..4032bf3 100644
> --- a/utils/mount/stropts.c
> +++ b/utils/mount/stropts.c
> @@ -665,9 +665,10 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
> case EHOSTUNREACH:
> continue;
> default:
> - break;
> + goto out;
> }
> }
> +out:
> return ret;
> }
>
> @@ -751,9 +752,10 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
> case EHOSTUNREACH:
> continue;
> default:
> - break;
> + goto out;
> }
> }
> +out:
> return ret;
> }
>
> --
> 1.7.1
>
--
"""
Keep It Simple,Stupid.
"""
Chinese Name: 白杨
Nick Name: Hamo
Homepage: http://hamobai.com/
GPG KEY ID: 0xA4691A33
Key fingerprint = 09D5 2D78 8E2B 0995 CF8E 4331 33C4 3D24 A469 1A33
What was the presenting problem? Is there a bugzilla report I can look at?
On Oct 11, 2011, at 5:44 AM, Hamo wrote:
> We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH
> for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
> Before, only a break in swich can not make the program out of for loop.
>
> Signed-off-by: Yang Bai <[email protected]>
> ---
> utils/mount/stropts.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
> index 314a806..4032bf3 100644
> --- a/utils/mount/stropts.c
> +++ b/utils/mount/stropts.c
> @@ -665,9 +665,10 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
> case EHOSTUNREACH:
> continue;
> default:
> - break;
> + goto out;
> }
> }
> +out:
> return ret;
> }
>
> @@ -751,9 +752,10 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
> case EHOSTUNREACH:
> continue;
> default:
> - break;
> + goto out;
> }
> }
> +out:
> return ret;
> }
>
> --
> 1.7.1
> --
> 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
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Looking further into this issue, I noticed all the following
mounts were successful.
# mount -o v3 localhost:/home /mnt/home
# mount -o v4 localhost:/home /mnt/home
# mount -o v4 [fec0::2:5652:ff:fe20:8459]:/home /mnt/home
# mount -o v3 [fec0::2:5652:ff:fe20:8459]:/home /mnt/home
which the mount point, /mnt/home is mounted 4 different times
to the same server.
Is by design or a real problem?
steved.
On 10/13/2011 12:34 PM, Steve Dickson wrote:
> Yeah... I believe its this one
> https://bugzilla.redhat.com/show_bug.cgi?id=744657
>
> On 10/13/2011 10:53 AM, Chuck Lever wrote:
>> What was the presenting problem? Is there a bugzilla report I can look at?
>>
>> On Oct 11, 2011, at 5:44 AM, Hamo wrote:
>>
>>> We should only try next address family if we meet ECONNREFUSED or EHOSTUNREACH
>>> for v4 or ECONNREFUSED or EOPNOTSUPP or EHOSTUNREACH for v3v2.
>>> Before, only a break in swich can not make the program out of for loop.
>>>
>>> Signed-off-by: Yang Bai <[email protected]>
>>> ---
>>> utils/mount/stropts.c | 6 ++++--
>>> 1 files changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
>>> index 314a806..4032bf3 100644
>>> --- a/utils/mount/stropts.c
>>> +++ b/utils/mount/stropts.c
>>> @@ -665,9 +665,10 @@ static int nfs_try_mount_v3v2(struct nfsmount_info *mi)
>>> case EHOSTUNREACH:
>>> continue;
>>> default:
>>> - break;
>>> + goto out;
>>> }
>>> }
>>> +out:
>>> return ret;
>>> }
>>>
>>> @@ -751,9 +752,10 @@ static int nfs_try_mount_v4(struct nfsmount_info *mi)
>>> case EHOSTUNREACH:
>>> continue;
>>> default:
>>> - break;
>>> + goto out;
>>> }
>>> }
>>> +out:
>>> return ret;
>>> }
>>>
>>> --
>>> 1.7.1
>>> --
>>> 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
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/