Change in multiple NFS mount behavior in 2.6.19?

Change in multiple NFS mount behavior in 2.6.19?

[Mike Accetta]

After upgrading an NFS client from 2.6.18 to 2.6.19 (and also with 
2.6.19.1) we see a change in behavior of multiple NFS mounts against the 
same server (running 2.4.20 in this case).  With 2.6.18 we could mount 
different pieces of the same remote file system with distinct read-only 
and read-write attributes at corresponding places on the client.  With 
2.6.19 if the first mount is read-only, subsequent mounts seem to 
inherit the read-only status even though not explicitly mounted read-only.

If I did the "git bisect" properly, the behavior changed with commit
54ceac4515986030c2502960be620198dd8fe25b and the description of this 
commit seems like it could indeed have caused this behavior, but perhaps 
not intentionally. I believe the client is making NFS V2 calls. Also, I 
am still able to issue a "mount -o remount,rw" on the client to regain 
read-write capability.  Was this a regression or is this now the 
expected behavior for multiple NFS client mounts in 2.6.19?
-- 
Mike Accetta

ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)

Re: Change in multiple NFS mount behavior in 2.6.19?

[Randy Dunlap]

On Fri, 15 Dec 2006 23:46:28 -0500 Mike Accetta wrote:

> After upgrading an NFS client from 2.6.18 to 2.6.19 (and also with 
> 2.6.19.1) we see a change in behavior of multiple NFS mounts against the 
> same server (running 2.4.20 in this case).  With 2.6.18 we could mount 
> different pieces of the same remote file system with distinct read-only 
> and read-write attributes at corresponding places on the client.  With 
> 2.6.19 if the first mount is read-only, subsequent mounts seem to 
> inherit the read-only status even though not explicitly mounted read-only.
> 
> If I did the "git bisect" properly, the behavior changed with commit
> 54ceac4515986030c2502960be620198dd8fe25b and the description of this 
> commit seems like it could indeed have caused this behavior, but perhaps 
> not intentionally. I believe the client is making NFS V2 calls. Also, I 
> am still able to issue a "mount -o remount,rw" on the client to regain 
> read-write capability.  Was this a regression or is this now the 
> expected behavior for multiple NFS client mounts in 2.6.19?
> -- 

That would correspond to this bugzilla item, which explains
that multiple mount semantics for one filesystem are all shared.

http://bugzilla.kernel.org/show_bug.cgi?id=7655

---
~Randy

Re: Change in multiple NFS mount behavior in 2.6.19?

[Mike Accetta]

Randy Dunlap wrote:
> On Fri, 15 Dec 2006 23:46:28 -0500 Mike Accetta wrote:
> 
>> After upgrading an NFS client from 2.6.18 to 2.6.19 (and also with 
>> 2.6.19.1) we see a change in behavior of multiple NFS mounts against the 
>> same server (running 2.4.20 in this case).  With 2.6.18 we could mount 
>> different pieces of the same remote file system with distinct read-only 
>> and read-write attributes at corresponding places on the client.  With 
>> 2.6.19 if the first mount is read-only, subsequent mounts seem to 
>> inherit the read-only status even though not explicitly mounted read-only.
>>
>> If I did the "git bisect" properly, the behavior changed with commit
>> 54ceac4515986030c2502960be620198dd8fe25b and the description of this 
>> commit seems like it could indeed have caused this behavior, but perhaps 
>> not intentionally. I believe the client is making NFS V2 calls. Also, I 
>> am still able to issue a "mount -o remount,rw" on the client to regain 
>> read-write capability.  Was this a regression or is this now the 
>> expected behavior for multiple NFS client mounts in 2.6.19?
>> -- 
> 
> That would correspond to this bugzilla item, which explains
> that multiple mount semantics for one filesystem are all shared.
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=7655

OK.  I didn't think to search bugzilla as I hadn't seen anything go by on the 
list.   Since this is now the expected behavior, I'll have to think about how 
to re-architect things.  Thanks for the pointer.
-- 
Mike Accetta

ECI Telecom Ltd.
Data Networking Division (previously Laurel Networks)