lkml.org 
[lkml]   [2007]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: recent nfs change causes autofs regression
Trond Myklebust wrote:
> On Thu, 2007-08-30 at 20:49 -0700, Linus Torvalds wrote:
>> Please send in a fix. If the fix involves making "nosharecache" the
>> default, then that is better than making policy decisions like this in the
>> kernel. The kernel should do what the user asks and not put in unnecessary
>> roadblocks.
>
> The best I can do given the constraints appears to be to have the kernel
> first look for a superblock that matches both the fsid and the
> user-specified mount options, and then spawn off a new superblock if
> that search fails. The attached patch does just that.
>
I'm glad I read the whole thread, because when I saw it earlier and
didn't respond, this was the question I had, why not replace the error
with forcing "nosharecache" on, which is essentially what you have done.

> Note that this is not the same as specifying nosharecache everywhere
> since nosharecache will never attempt to match an existing superblock.
>
> Finally, for the record: I still feel very uncomfortable about not being
> able to report the state of the client setup back to the sysadmin.
> AFAIK, the only way to do so is to stat the mountpoints, and compare the
> device ids.
>
Since clients may not know the server setup, and it may change for
policy or error recovery reason, I think this patch is needed.

The cases I think are common are:

1 - single export, multiple client mounts

export /base - rw

mount /base/share - ro [ client enforces r/o or not ]
mount /base/upload - rw

2 - export parts of a filesystem (/base) [ server enforces access ]

export /base/share - ro [ hopefully really r/o on client ]
export /base/upload - rw [ should work for write ]

3 - mount the same f/s with different permissions on client

export /base - rw

mount /base on point1 - rw [ hopefully really r/w ]
mount /base on point2 - ro [ hopefully r/o ]

I consider this *really* bad practice, but I have seen it in enough
places to know others don't agree. It assumes the client will protect
the r/o data.

4 - export f/s and part of f/s

export /base/ - ro
export /base/upload - rw

clients may mount one or both, with the upload directory as part of base
or elsewhere. What will happen here?

> Trond


--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-09-02 03:01    [W:0.120 / U:0.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site