Hi,
A nfs4 filesystem, mounted elsewhere via the "bind" option (the usual
way to do with nfsv4 and its pseudofs), reports wrong fstype "nfs"
instead of "nfs4" filesystem.
An example is much easier to understand :
Server-side :
- /exports is the pseudo root filesystem (fsid=0 option in /etc/exports)
- /exports/data is a mountpoint for another filesystem (not the same
device-id as /exports). This condition seems to be what triggers the bug
- /exports/data must be exported with the "nohide" option (again, the
usual way to do se with nfsv4)
Client-side :
- mount server:/ on /imports
- mount "bind" /imports/data on /home/data
(this magically shows a second nfs mount in /proc/mounts)
And here is the bug : this second mount is of fstype "nfs" instead of
"nfs4" although the options field contains "vers=4".
This is like a cosmetic bug, but this becomes a problem when some apps
need to differentiate nfs and nfs4 fstype (e.g. linuxquota uses it to
know how to handle the nfs source-path)
Gabriel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Aug 27, 2007 at 08:15:07PM +0100, Al Viro wrote:
> On Mon, Aug 27, 2007 at 02:40:59PM -0400, J. Bruce Fields wrote:
>
> > There's no reason not to just mount server:/exports/data directly at
> > /home/data; the bind mounts are just a workaround for the somewhat
> > primitive exports facility on the server side.
>
> Bullshit. Bindings are first-class operations on _client_, regardless
> of fs types involved.
I know. Did I say something to the contrary?
Maybe I was too terse; in more detail: the original poster appears to be
mounting server:/exports/data by first mounting server:/ somewhere and
then bind-mounting the exports/data someplace else. I couldn't see an
obvious reason they'd be using two steps instead of just performing a
single mount of server:/exports/data.
So my assumption was that this was due to a confused memory of some
server-side setup instructions. (On the server side, nfs4 export setup
often requires the administrator to do some extra bind mounts which
shouldn't really be necessary.)
--b.
On 08/27/2007 9:32:42 PM +0200, "J. Bruce Fields" <[email protected]>
wrote:
> On Mon, Aug 27, 2007 at 08:15:07PM +0100, Al Viro wrote:
>> On Mon, Aug 27, 2007 at 02:40:59PM -0400, J. Bruce Fields wrote:
>>
>>> There's no reason not to just mount server:/exports/data directly at
>>> /home/data; the bind mounts are just a workaround for the somewhat
>>> primitive exports facility on the server side.
>> Bullshit. Bindings are first-class operations on _client_, regardless
>> of fs types involved.
>
> I know. Did I say something to the contrary?
>
> Maybe I was too terse; in more detail: the original poster appears to be
> mounting server:/exports/data by first mounting server:/ somewhere and
> then bind-mounting the exports/data someplace else. I couldn't see an
> obvious reason they'd be using two steps instead of just performing a
> single mount of server:/exports/data.
>
> So my assumption was that this was due to a confused memory of some
> server-side setup instructions. (On the server side, nfs4 export setup
> often requires the administrator to do some extra bind mounts which
> shouldn't really be necessary.)
Right. When setting up the clients, I remembered these "bind" mount
things, and applied the same client-side because at this time I had
other bugs for which I thought "bind" mount was the solution. In fact
it's not, but as nfs4 is seen as a unique filesystem and I had several
exported volumes, It was easier to mount the nfsv4 pseudoroot, then
"bind" mount all the volumes from it.
But the bug's still here, and since these additional mounts appear
"magically" in /proc/mounts, I don't know where to look at in the kernel
source. The nfsv4 client code must have somewhere a kind of nfs4
automounter for "nohide" volumes. A bit ugly IMHO, but the only way to
show quotas for separates nfsv4 exported volumes too.
Gabriel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Aug 27, 2007 at 08:32:51PM +0200, Gabriel Barazer wrote:
> Hi,
>
> A nfs4 filesystem, mounted elsewhere via the "bind" option (the usual
> way to do with nfsv4 and its pseudofs), reports wrong fstype "nfs"
> instead of "nfs4" filesystem.
> An example is much easier to understand :
> Server-side :
> - /exports is the pseudo root filesystem (fsid=0 option in /etc/exports)
> - /exports/data is a mountpoint for another filesystem (not the same
> device-id as /exports). This condition seems to be what triggers the bug
> - /exports/data must be exported with the "nohide" option (again, the
> usual way to do se with nfsv4)
>
> Client-side :
> - mount server:/ on /imports
> - mount "bind" /imports/data on /home/data
There's no reason not to just mount server:/exports/data directly at
/home/data; the bind mounts are just a workaround for the somewhat
primitive exports facility on the server side.
> (this magically shows a second nfs mount in /proc/mounts)
> And here is the bug : this second mount is of fstype "nfs" instead of
> "nfs4" although the options field contains "vers=4".
But, yes, that sounds like a bug, thanks.
--b.
On Mon, Aug 27, 2007 at 02:40:59PM -0400, J. Bruce Fields wrote:
> There's no reason not to just mount server:/exports/data directly at
> /home/data; the bind mounts are just a workaround for the somewhat
> primitive exports facility on the server side.
Bullshit. Bindings are first-class operations on _client_, regardless
of fs types involved.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs