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

Hika van den Hoven hikavdh at gmail.com
Thu Jun 5 17:27:38 UTC 2014


Hoi John,

Thursday, June 5, 2014, 6:35:44 PM, you wrote:

> 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.

Again not removing but made inaccessible on the client by stale
filehandles on the bottom nfs mount. Which is only solvable by a
rebind which is impossible because of the inaccessible child
mountpoints which need to be unmounted for that!!!!
Thus making a reboot the only solution. There should be a command to
evaluate cq clear those filehandles, but there isn't! In essence NFS
is not capable of reliable handling a sometimes less then 100%
available/stable network connection. It does not always properly recover.
This unlike CIFS.

Tot mails,
  Hika                            mailto:hikavdh at gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens



More information about the mythtv-users mailing list