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
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
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
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
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
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, 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 flag into
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-kernel
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
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 NFS
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 Al Viro probably
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
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
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
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
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't
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
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 about
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 what
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:
--- 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
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
--- 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 believe
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
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
> 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
> 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
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
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
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
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
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
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
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
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
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
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
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
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:
> >
> >
> > 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
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
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 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 should
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
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 setups which
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
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 the
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 spawn off a
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 if the
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
if
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 Linus
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
fix them
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 the
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, then that
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:
regression
It's
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 fail
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
--- 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 setup, at least.
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
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 was a
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 before (and
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 least
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
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
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
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
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.
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"
> 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.
>
>
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
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
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
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
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
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
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
> 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
>
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
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
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 silently
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 mounts to
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: upgrading to
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
mount' is actually
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 I
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 these
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 problem:
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 obviously
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 tomorrow.
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.
I
1 - 100 of 111 matches
Mail list logo
