If people try mounting several exports from the same filesystem, it fails with confusing error messages if the mount options are different for some of the mount points. Adding "nosharecache" to the mount options fixes that, but people with working setups suddenly find they need this new option to use a setup that used to work without it. Should we just revert that patch?
On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote:
If people try mounting several exports from the same filesystem, it fails with confusing error messages if the mount options are different for some of the mount points. Adding "nosharecache" to the mount options fixes that, but people with working setups suddenly find they need this new option to use a setup that used to work without it. Should we just revert that patch?
Adding steved to cc (I don't think he's on the list).
Dave
Dave Jones wrote:
On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote:
If people try mounting several exports from the same filesystem, it fails with confusing error messages if the mount options are different for some of the mount points. Adding "nosharecache" to the mount options fixes that, but people with working setups suddenly find they need this new option to use a setup that used to work without it. Should we just revert that patch?
Thats been the million dollar question lately... there has been quite a bit of complaints about this patch... but note the check does do some correct sanity checking so the changes it point would be a good thing to do....
But with that said, I would if making it a warning first, giving people time to clean up their setups and then making it an error later on...
steved.
On 08/21/2007 12:14 PM, Steve Dickson wrote:
Dave Jones wrote:
On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote:
If people try mounting several exports from the same filesystem, it
fails
with confusing error messages if the mount options are different
for some
of the mount points. Adding "nosharecache" to the mount options
fixes that,
but people with working setups suddenly find they need this new
option to
use a setup that used to work without it. Should we just revert
that patch?
Thats been the million dollar question lately... there has been quite a bit of complaints about this patch... but note the check does do some correct sanity checking so the changes it point would be a good thing to do....
But with that said, I would if making it a warning first, giving people time to clean up their setups and then making it an error later on...
Can't it be made to automatically set the nosharecache flag if it's needed?
Chuck Ebbert wrote:
On 08/21/2007 12:14 PM, Steve Dickson wrote:
Dave Jones wrote:
On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote:
If people try mounting several exports from the same filesystem, it
fails
with confusing error messages if the mount options are different
for some
of the mount points. Adding "nosharecache" to the mount options
fixes that,
but people with working setups suddenly find they need this new
option to
use a setup that used to work without it. Should we just revert
that patch?
Thats been the million dollar question lately... there has been quite a bit of complaints about this patch... but note the check does do some correct sanity checking so the changes it point would be a good thing to do....
But with that said, I would if making it a warning first, giving people time to clean up their setups and then making it an error later on...
Can't it be made to automatically set the nosharecache flag if it's needed?
thats is an idea that has been kicked around but it turns out it becomes very messy very quickly...
steved.
On Tue, 2007-08-21 at 12:14 -0400, Steve Dickson wrote:
Dave Jones wrote:
On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote:
If people try mounting several exports from the same filesystem, it fails with confusing error messages if the mount options are different for some of the mount points. Adding "nosharecache" to the mount options fixes that, but people with working setups suddenly find they need this new option to use a setup that used to work without it. Should we just revert that patch?
Thats been the million dollar question lately... there has been quite a bit of complaints about this patch... but note the check does do some correct sanity checking so the changes it point would be a good thing to do....
But with that said, I would if making it a warning first, giving people time to clean up their setups and then making it an error later on...
steved.
It is important that people know about the consequences of using nosharecache: namely that they may see cache corruption when accessing the same file via different mountpoints. That is why I firmly believe it should _NOT_ be a default.
Trond
Dave Jones wrote:
On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote:
If people try mounting several exports from the same filesystem, it fails with confusing error messages if the mount options are different for some of the mount points. Adding "nosharecache" to the mount options fixes that, but people with working setups suddenly find they need this new option to use a setup that used to work without it. Should we just revert that patch?
Just curious... What are the differences in the mounts options that is causing this new check to pop, which in turn is failing the mount?
steved.
On 08/22/2007 11:18 AM, Steve Dickson wrote:
Dave Jones wrote:
On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote:
If people try mounting several exports from the same filesystem, it
fails
with confusing error messages if the mount options are different
for some
of the mount points. Adding "nosharecache" to the mount options
fixes that,
but people with working setups suddenly find they need this new
option to
use a setup that used to work without it. Should we just revert
that patch?
Just curious... What are the differences in the mounts options that is causing this new check to pop, which in turn is failing the mount?
In at least one case it is read-only vs. read-write. User mounts something from the server read-only, then mounts selected exports from the same filesystem read-write on top of that.
Chuck Ebbert wrote:
On 08/22/2007 11:18 AM, Steve Dickson wrote:
Dave Jones wrote:
On Tue, Aug 21, 2007 at 10:29:53AM -0400, Chuck Ebbert wrote:
If people try mounting several exports from the same filesystem, it
fails
with confusing error messages if the mount options are different
for some
of the mount points. Adding "nosharecache" to the mount options
fixes that,
but people with working setups suddenly find they need this new
option to
use a setup that used to work without it. Should we just revert
that patch?
Just curious... What are the differences in the mounts options that is causing this new check to pop, which in turn is failing the mount?
In at least one case it is read-only vs. read-write.
This should not make the check pop...
User mounts something from the server read-only, then mounts selected exports from the same filesystem read-write on top of that.
The check looks for difference protocols, I/O sizes, or cache timeouts so there has to be something other ro/rw that is causing the mounts to fail...
steved.
On 08/22/2007 11:36 AM, Steve Dickson wrote:
Just curious... What are the differences in the mounts options that is causing this new check to pop, which in turn is failing the mount?
In at least one case it is read-only vs. read-write.
This should not make the check pop...
User mounts something from the server read-only, then mounts selected exports from the same filesystem read-write on top of that.
The check looks for difference protocols, I/O sizes, or cache timeouts so there has to be something other ro/rw that is causing the mounts to fail...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253530
This may be some other problem, user changed to r/w and the problem went away:
kernel@lists.fedoraproject.org
-
Chuck Ebbert -
Dave Jones -
Steve Dickson -
Trond Myklebust