[mythtv-users] Shared filesystem that looks different to different machines

[John Finlay]

On 6/4/2014 3:55 PM, Hika van den Hoven wrote:
> Hoi John,
>
> Thursday, June 5, 2014, 12:29:56 AM, you wrote:
>
>> On 6/4/2014 2:15 PM, Hika van den Hoven wrote:
>>> Hoi John,
>>>
>>> Wednesday, June 4, 2014, 11:17:49 PM, you wrote:
>>>
>>>> On 6/4/2014 10:39 AM, Hika van den Hoven wrote:
>>>>> Hoi John,
>>>>>
>>>>> Wednesday, June 4, 2014, 6:26:17 PM, you wrote:
>>>>>
>>>>>> On 6/4/2014 8:20 AM, Raymond Wagner wrote:
>>>>>>> On 6/4/2014 10:53 AM, Joseph Fry wrote:
>>>>>>>> I don't believe that NFS would have any issue with nesting a mount
>>>>>>>> inside another mount like this, after all the OS just treats it as
>>>>>>>> another filesystem and every linux system I have ever seen does this
>>>>>>>> (/dev, /proc, etc).
>>>>>>> NFS can have issues if you mount one NFS volume within another NFS
>>>>>>> volume.  If access to the lower volume is ever anything but 100%
>>>>>>> stable, and the mount point for the upper volume is lost, bad things
>>>>>>> happen.  It's the same reason why you never use an NFS share for swap
>>>>>>> space.
>>>>>> Mounting one NFS filesystem on another NFS filesystem has been commonly
>>>>>> used from the beginning of NFS: diskless systems did this all the time.
>>>>> True, but if the bottom nfs filesystem gets dirty, which is very
>>>>> common if it is accessed by more then one client, you cannot access it
>>>>> anymore nor can you remount. You have to reboot.
>>>>>
>>>>>
>>>>>
>>>> I'm not sure what you mean by the above but my understanding and
>>>> experience is that NFS was designed to be accessed (i.e. read and write)
>>>> by more than one client and not have problems. If someone removed the
>>>> directory that is being used as the mount point then I can see how that
>>>> would be a problem but otherwise. Also my experience has been that
>>>> mounting NFS filesystems from different servers is a valid configuration
>>>> and works as expected.
>>>> _______________________________________________
>>> I might not say it correctly. Every client keeps the filestructure of
>>> the share. If another client or the server makes changes that kept
>>> structure is no longer valid. The connection is dirty. If that happens
>>> to the bottom share the subshares are no longer accessible, but are at
>>> the same time blocking a refresh. So you get a deadlock you can only
>>> solve by rebooting.
>>>
>>>
>> Your terminology sounds more like CIFS than NFS. It sounds like you are
>> saying that if someone does something stupid like remove the mount
>> point(s) for client NFS mounts then the client will have a problem. I'm
>> not sure that's a problem with NFS.
> No CIFS is much more robust. The local cached data about a NFS share
> gets dirty if another client changes data. If that also includes data
> about other shares mounted on that share, your system cannot access
> those anymore. Not because the mountpoints are gone but because they
> are inaccessible. This will block a refresh of the local cashed data.
> Until I stopt mounting nfs on nfs I had it regularly and I did a lot
> of research into it. It's one of the reasons I'm considering moving to
> CIFS in linux.
>
>
Like I said removing the directories used by clients as NFS mountpoints 
is an administrative mistake.