[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Buyer Beware: A Major Change in NFS is about to happen

On 09/30/2009 11:07 AM, Howard Wilkinson wrote:
>>>> With version 4 there is this concept of a pseudo root. Which meanings
>>>> one can define, through exports, what the root of an export
>>>> can be. Which is a good idea because you can define /export as
>>>> the root, and nothing above /export can be accessed... 
>>> But if there is a /data *(ro,fsid=0) export then that will do, but it
>>> becomes the root of the export tree against which mounts are made?
>> Yes.. For example say the directory tree under /data looks like
>>    /data
>>         dir1/
>>             subdir1/
>>         dir2/
>>             subdir2/
>> Then the client could do a
>>      mount server:/ /mnt/
>> which would make every thing under /data visible, meaning
>>      ls /mnt/dir1
>>      ls /mnt/dir2
>> Now the client could also do a
>>      mount server:/dir1 /mnt
>> which would only make the the directories under /data/dir1 visible, meaning
>>     ls /mnt/subdir1
> This is the scheme we use here already and we are running V4 on
> everything except the kickstart network based builds as that only seems
> to understand V3. This is F11 with a few additions from F12 backported.
This is good  to hear...

>>>> With F-12, I have added code to both the kernel and nfs-utils that will 
>>>> do both. Allow the 'fsid=0' export to define the pseudo root and 
>>>> make '/' the pseudo root (with the appropriate protections) when
>>>> there is not an fsid=0 entry.
>>>> So Yes, one work around to make F-12 mounts work with Linux servers is 
>>>> to define a pseudo root on the server with a fsid=0 export. But if
>>>> that is not an option, you can make the F12 clients only use V3 mount
>>>> (which would avoid the problem, but not take advantage of the
>>>> V4 protocol) by set either setting the '-o v3' mount option or 
>>>> set the Nfsvers=3 in the new /etc/nfsmount.conf file (which would make
>>>> all mounts from that machine v3 mounts).
>>> But the downside of the / *(ro,fsid=0) approach is we now have all of
>>> the root files (but not any other filing systems visible).
>> No, other mounts files systems would be visible as well..
> That is not what we see today - at least I do not think so. We still
> have to add exports statements to get filing system transitions to
> export.
Try adding either 'nohide' or 'crossmnt' on your other exports...

>>> So perhaps a better approach would be to specify a /V4root *(ro,fsid=0)
>>> directory being created and a bind mount for each export from the pre-V3
>>> name space being made into that tree. Or have I missed something
>>> entirely?
>> That sounds like it could work, although it may not be too scalable with
>> large and complicated export tree... 
> Works with a medium size network here - we export about 100 filing
> systems in a single tree!
>> The real answer is use a F-12 NFS server since all this stuff goes away..
> Does that mean the F12 provides V4 servers for preference and F11 does
> not? 
For now yes... but due to the all the excitement that has generated
an adjustment might be made... ;-) 

> I must have done something in the past to make F11 serve V4 by
> default then - wonder what it was?

You must be set the '-t nfs4' fileystem type.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]