On Wed, 2007-09-05 at 16:50 +0100, Trond Myklebust wrote:
> On Wed, 2007-09-05 at 16:37 +0100, David Howells wrote:
> > Ian Kent <[EMAIL PROTECTED]> wrote:
> >
> > > But what about mounting with different protocol, tcp vs udp for example.
> >
> > I was referring specifically to the R/O / R/W vari
On Wed, 2007-09-05 at 20:44 +0800, Ian Kent wrote:
> On Tue, 2007-09-04 at 08:54 +0100, David Howells wrote:
> > Bill Davidsen <[EMAIL PROTECTED]> wrote:
> >
> > > mount /base on point1 - rw[ hopefully really r/w ]
> > > mount /base on point2 - ro[ hopefully r/o ]
> >
> > I think
On Wed, 2007-09-05 at 16:37 +0100, David Howells wrote:
> Ian Kent <[EMAIL PROTECTED]> wrote:
>
> > But what about mounting with different protocol, tcp vs udp for example.
>
> I was referring specifically to the R/O / R/W variants of the same mount. Any
> flag variation that varies the way the
Ian Kent <[EMAIL PROTECTED]> wrote:
> But what about mounting with different protocol, tcp vs udp for example.
I was referring specifically to the R/O / R/W variants of the same mount. Any
flag variation that varies the way the NFS client talks to the NFS server must
either result in a new super
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> I think Al had a good idea there, that is nice and clean. What about bind
> mounts, will that just fall out?
I don't see that it should be a problem since the vfsmount is copied.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Tue, 2007-09-04 at 08:54 +0100, David Howells wrote:
> Bill Davidsen <[EMAIL PROTECTED]> wrote:
>
> > mount /base on point1 - rw [ hopefully really r/w ]
> > mount /base on point2 - ro [ hopefully r/o ]
>
> I think Al Viro probably has the right idea as to how to fix this: Move the
> R/O R/W
David Howells wrote:
Bill Davidsen <[EMAIL PROTECTED]> wrote:
mount /base on point1 - rw [ hopefully really r/w ]
mount /base on point2 - ro [ hopefully r/o ]
I think Al Viro probably has the right idea as to how to fix this: Move the
R/O R/W flag into vfsmount and count the
On Tue, 4 Sep 2007, David Howells wrote:
>
> That helps one case, yes, but what about a superset? What about two sets that
> might intersect but for which you don't have the common root to hand?
Sure. In which case bind mounts don't work. Fair enough.
> The case I came up with was this:
>
>
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> In other words, let's assume that the user has /some/nfs/mount mounted
> over NFS, and wants to re-mount it (or even just a subset of it) somewhere
> else, the sane thing to do is not to mount it again, but to just do
That helps one case, yes, but wha
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> In other words, let's assume that the user has /some/nfs/mount mounted
> over NFS, and wants to re-mount it (or even just a subset of it) somewhere
> else, the sane thing to do is not to mount it again, but to just do
What about a superset? What abou
Bill Davidsen <[EMAIL PROTECTED]> wrote:
> mount /base on point1 - rw[ hopefully really r/w ]
> mount /base on point2 - ro[ hopefully r/o ]
I think Al Viro probably has the right idea as to how to fix this: Move the
R/O R/W flag into vfsmount and count the number of R/W vfsmounts in the
s
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> - the NFSv4 delegation model breaks: the client will be using
> OPEN when it could use cached opens. More importantly, when
> performing an operation that requires it to return the
> delegation on the aliased file, it won
--- Jakob Oestergaard <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 31, 2007 at 09:43:29AM -0700, Linus Torvalds wrote:
> ...
> > This is *not* a security hole. In order to make it a security hole,
> you
> > need to be root in the first place.
>
> Non-root users can write to places where root might
On Fri, Aug 31, 2007 at 09:43:29AM -0700, Linus Torvalds wrote:
...
> This is *not* a security hole. In order to make it a security hole, you
> need to be root in the first place.
Non-root users can write to places where root might believe they cannot write
because he might be under the mistaken
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 unnecessa
> It's not about default (for which backward compatibility is most
> important and this patch is perfectly fine), but user explicitly asks
> for "sharecache". In this case if for any reason the cache cannot be
> shared, I am not sure if he should get an error back.
>
> I for one agree with Ian and
> On Fri, 2007-08-31 at 11:47 -0700, Hua Zhong wrote:
> > This patch fixes the problem for me, thanks.
> >
> > Is this patch changing the behavior of "sharecache" to
> > "try-to-share-cache-if-possible", or adding a third behavior? If the
> > user explicitly asks for "-o sharecache", does he get an
On Fri, 2007-08-31 at 11:47 -0700, Hua Zhong wrote:
> This patch fixes the problem for me, thanks.
>
> Is this patch changing the behavior of "sharecache" to
> "try-to-share-cache-if-possible", or adding a third behavior? If the user
> explicitly asks for "-o sharecache", does he get an error back
On Fri, 2007-08-31 at 10:01 -0700, Linus Torvalds wrote:
>
> On Fri, 31 Aug 2007, Trond Myklebust wrote:
> >
> > 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 sp
This patch fixes the problem for me, thanks.
Is this patch changing the behavior of "sharecache" to
"try-to-share-cache-if-possible", or adding a third behavior? If the user
explicitly asks for "-o sharecache", does he get an error back if the mount
options mismatch?
> The best I can do given th
On Fri, 31 Aug 2007, Trond Myklebust wrote:
>
> 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.
I think this is pr
On Fri, 31 Aug 2007, Jakob Oestergaard wrote:
>
> > The fact that he may *also* have broken insane setups is totally
> > irrelevant. Don't go off on some tangent that has nothing to do with the
> > regression in question!
>
> It does not have "nothing" to do with the regression.
>
> Some set
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.
On Fri, Aug 31, 2007 at 09:50:12AM -0400, Trond Myklebust wrote:
> On Fri, 2007-08-31 at 15:12 +0200, Frank van Maarseveen wrote:
>
> > IMHO I'd only consider returning EBUSY when trying to mount _exactly_
> > the same directory with different flags, not for arbitrary subtrees. The
> > client shou
On Fri, 2007-08-31 at 15:12 +0200, Frank van Maarseveen wrote:
> IMHO I'd only consider returning EBUSY when trying to mount _exactly_
> the same directory with different flags, not for arbitrary subtrees. The
> client should preferably not be bothered with server side disk
> partitioning (at leas
On Fri, Aug 31, 2007 at 08:11:38AM -0400, Trond Myklebust wrote:
> On Fri, 2007-08-31 at 01:07 -0700, Linus Torvalds wrote:
> >
>
> > If you want new behaviour, you add a new flag saying you want new
> > behaviour. You don't just start behaving differently from what you've
> > always done befor
On Fri, 2007-08-31 at 01:07 -0700, Linus Torvalds wrote:
>
> If you want new behaviour, you add a new flag saying you want new
> behaviour. You don't just start behaving differently from what you've
> always done before (and what *other* UNIXes do, for that matter).
>
> Besides, even *if* it w
On Fri, 31 Aug 2007, Frank van Maarseveen wrote:
> On Thu, Aug 30, 2007 at 02:07:43PM -0700, Hua Zhong wrote:
> > I am re-sending this after help from Ian and git-bisect. To me it's a
> > show-stopper: I cannot find an acceptable workaround that I can implement.
> >
> > The problem: upgrading to
--- Ian Kent <[EMAIL PROTECTED]> wrote:
> On Thu, 30 Aug 2007, Linus Torvalds wrote:
> >
> >
> > On Fri, 31 Aug 2007, Trond Myklebust wrote:
> > >
> > > It did not. The previous behaviour was to always silently
> override the
> > > user mount options.
> >
> > ..so it still worked for any sane
On Fri, Aug 31, 2007 at 01:07:56AM -0700, Linus Torvalds wrote:
...
> When we add NEW BEHAVIOUR, we don't add it to old interfaces when that
> breaks old user mode! We add a new flag saying "I want the new behaviour".
>
> This is not rocket science, guys. This is very basic kernel behaviour. The
On Thu, Aug 30, 2007 at 02:07:43PM -0700, Hua Zhong wrote:
> I am re-sending this after help from Ian and git-bisect. To me it's a
> show-stopper: I cannot find an acceptable workaround that I can implement.
>
> The problem: upgrading to 2.6.23-rc4 from 2.6.22 causes several autofs
> mounts to fai
On Fri, Aug 31, 2007 at 09:40:28AM +0200, Jakob Oestergaard wrote:
> On Thu, Aug 30, 2007 at 10:16:37PM -0700, Linus Torvalds wrote:
> >
> ...
> > > Why aren't we doing that for any other filesystem than NFS?
> >
> > How hard is it to acknowledge the following little word:
> >
> > "regressio
> > It's not very conservative to suddenly change default behavior and break
> > autofs mounts. There is not even one kernel message that "_tells_ user why
> > it thinks it's wrong". It just silently fails.
>
> No it doesn't. It reports an error code to the caller. If autofs is
> failing silently,
On Fri, 31 Aug 2007, Jakob Oestergaard wrote:
>
> Trond has a point Linus.
I don't dispute that the new code does somethign good.
But it changes existing behaviour.
When we add NEW BEHAVIOUR, we don't add it to old interfaces when that
breaks old user mode! We add a new flag saying "I want t
On Thu, Aug 30, 2007 at 10:16:37PM -0700, Linus Torvalds wrote:
>
...
> > Why aren't we doing that for any other filesystem than NFS?
>
> How hard is it to acknowledge the following little word:
>
> "regression"
>
> It's simple. You broke things. You may want to fix them, but you need to
On Thu, 30 Aug 2007, Linus Torvalds wrote:
>
>
> On Fri, 31 Aug 2007, Trond Myklebust wrote:
> >
> > It did not. The previous behaviour was to always silently override the
> > user mount options.
>
> ..so it still worked for any sane setup, at least.
>
> You broke that. Hua gave good reasons f
Trond,
> So you are saying that it is acceptable for the kernel to decide
> unilaterally to override mount options? Why aren't we doing that for
> any other filesystem than NFS?
I think there are two reasons.
First, I have no problem with the new behavior if it didn't cause a
regression. I am no
On Fri, 31 Aug 2007, Trond Myklebust wrote:
>
> So you are saying that it is acceptable for the kernel to decide
> unilaterally to override mount options?
IT'S WHAT WE'VE APPARENTLY ALWAYS DONE!
> Why aren't we doing that for any other filesystem than NFS?
How hard is it to acknowledge the fo
On Fri, 31 Aug 2007, Trond Myklebust wrote:
> On Thu, 2007-08-30 at 16:44 -0700, Hua Zhong wrote:
> > > How is the NFS client to know that these directories are disjoint, or
> > > that no-one will ever create a hard link from one directory to another?
> > > To my knowledge, the only way to ensure
On Thu, 2007-08-30 at 21:59 -0700, Linus Torvalds wrote:
>
> On Fri, 31 Aug 2007, Trond Myklebust wrote:
> >
> > It did not. The previous behaviour was to always silently override the
> > user mount options.
>
> ..so it still worked for any sane setup, at least.
>
> You broke that. Hua gave goo
On Fri, 31 Aug 2007, Trond Myklebust wrote:
>
> It did not. The previous behaviour was to always silently override the
> user mount options.
..so it still worked for any sane setup, at least.
You broke that. Hua gave good reasons for why he cannot use the current
kernel. It's a regression.
I
On Thu, 2007-08-30 at 21:38 -0700, Linus Torvalds wrote:
>
> On Fri, 31 Aug 2007, Trond Myklebust wrote:
> >
> > No. Solaris defaults to breaking cache consistency.
>
> If so, and since that's obviously what people _expect_ to happen, why not
> make that the default, with the "consistent" behav
> On Fri, 31 Aug 2007, Trond Myklebust wrote:
> >
> > No. Solaris defaults to breaking cache consistency.
>
> If so, and since that's obviously what people _expect_ to happen, why
> not make that the default, with the "consistent" behaviour being the
> one that needs an explicit option.
>
> Just
On Thu, 2007-08-30 at 20:49 -0700, Linus Torvalds wrote:
>
> On Thu, 30 Aug 2007, Trond Myklebust wrote:
> >
> > Which is better than having it fail silently, or giving you a mount with
> > the wrong mount options.
>
> No, Trond.
>
> That commit gets reverted or fixed. It's a regression, and yo
On Fri, 31 Aug 2007, Trond Myklebust wrote:
>
> No. Solaris defaults to breaking cache consistency.
If so, and since that's obviously what people _expect_ to happen, why not
make that the default, with the "consistent" behaviour being the one that
needs an explicit option.
Just out of curios
On Thu, 2007-08-30 at 16:44 -0700, Hua Zhong wrote:
> > How is the NFS client to know that these directories are disjoint, or
> > that no-one will ever create a hard link from one directory to another?
> > To my knowledge, the only way to ensure this is to put them on
> > different disk partitions.
On Thu, 2007-08-30 at 18:24 -0700, Andrew Morton wrote:
> On Thu, 30 Aug 2007 18:37:13 -0400 Trond Myklebust <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-08-30 at 14:07 -0700, Hua Zhong wrote:
> > > I am re-sending this after help from Ian and git-bisect. To me it's a
> > > show-stopper: I cannot
Hi Linus,
> Hua - that said, I don't actually see why the commit you bisected to
> has anything to do with the issue being discussed. Can you double-check
> that it's literally that particular commit that breaks for you (you could
> try just reverting that commit).
I will double check that tomorr
On Thu, 30 Aug 2007, Trond Myklebust wrote:
>
> Which is better than having it fail silently, or giving you a mount with
> the wrong mount options.
No, Trond.
That commit gets reverted or fixed. It's a regression, and your theories
that it's "better" that way are obviously broken.
It's obvio
On Thu, 30 Aug 2007 18:37:13 -0400 Trond Myklebust <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-08-30 at 14:07 -0700, Hua Zhong wrote:
> > I am re-sending this after help from Ian and git-bisect. To me it's a
> > show-stopper: I cannot find an acceptable workaround that I can implement.
> >
> > The
> How is the NFS client to know that these directories are disjoint, or
> that no-one will ever create a hard link from one directory to another?
> To my knowledge, the only way to ensure this is to put them on
> different disk partitions.
>
> I don't know if all Unix systems have this issue, but
On Thu, 2007-08-30 at 16:30 -0700, Hua Zhong wrote:
> There are two disjoint directories. I am wondering why there would be cache
> coherency issues in this case? Is this Linus nfs implementation specific or
> all other Unix systems all have the same issue?
How is the NFS client to know that thes
> On Thu, 2007-08-30 at 15:47 -0700, Hua Zhong wrote:
> > >
> > > Which is better than having it fail silently, or giving you a mount
> > > with the wrong mount options.
> >
> > Well, it depends on how you define "better".
>
> "better" as in: "I now have a chance to notice, when my 'read-only
> mo
On Thu, 2007-08-30 at 15:47 -0700, Hua Zhong wrote:
> Hi Trond,
>
> > On Thu, 2007-08-30 at 14:07 -0700, Hua Zhong wrote:
> > > I am re-sending this after help from Ian and git-bisect. To me it's a
> > > show-stopper: I cannot find an acceptable workaround that I can
> > > implement. The problem:
Hi Trond,
> On Thu, 2007-08-30 at 14:07 -0700, Hua Zhong wrote:
> > I am re-sending this after help from Ian and git-bisect. To me it's a
> > show-stopper: I cannot find an acceptable workaround that I can
> > implement. The problem: upgrading to 2.6.23-rc4 from 2.6.22 causes
> > several autofs m
On Thu, 2007-08-30 at 14:07 -0700, Hua Zhong wrote:
> I am re-sending this after help from Ian and git-bisect. To me it's a
> show-stopper: I cannot find an acceptable workaround that I can implement.
>
> The problem: upgrading to 2.6.23-rc4 from 2.6.22 causes several autofs
> mounts to fail silen
56 matches
Mail list logo
