Re: 答复: Re: 转发: file operation is interruptedwhenusingctdb+nfs

[ronnie sahlberg]

If the filehandles are the same, then it must be some other of the
internal state in Ganesha that is causing the stale filehandles.
Can you try using the normal linux kernel nfs server instead of ganesha?


Ganesha folks did not want to use ctdb databases to synchronize state
among the nodes and instead use their own
cross-node metadata synchronization primitives.
You may need to ask the Ganesha folks about this as they invented
their own solution, i.e. not ctdb metadata databases :-(




On Mon, Jan 8, 2018 at 4:40 PM, zhu.shangzhong--- via samba-technical
<samba-technical at lists.samba.org> wrote:
>> So the problem occurs even with consistent file handles? Hmmm...
>    Yes.
>> * Does the partial file exist in the cluster fileystem when the "stale
>> file handle" message is printed?
>    Yes.
>> * Is the filesystem mounted after the failover? Can you use "ls" to
>> list a directory on the client?
> Yes. The filesystem is mounted successfully after the failover.
>> * What happens if you disable a node with "ctdb disable"? Do you get a
>> clean failover?
> The same message "stale file handle" is output also.
> Yes, The node's virtual IP will be move to another. The failover works well.
>
> ------------------原始邮件------------------
> 发件人： <samba-technical at lists.samba.org>;
> 收件人： <samba-technical at lists.samba.org>;
> 抄送人：朱尚忠10137461;
> 日 期 ：2018年01月08日 13:59
> 主 题 ：Re: 转发: file operation is interruptedwhenusingctdb+nfs
> On Sat, 6 Jan 2018 18:01:24 +0800 (CST), "zhu.shangzhong--- via
> samba-technical" <samba-technical at lists.samba.org> wrote:
>
>> I try to remove the node 192.168.1.10, and use two nodes to test it.
>> The "stale file handle" message will be output also.
>>
>> [root at ceph ctdb]# onnode all stat -c '%d:%i' /tmp/test/nfs-test-1.iso
>> >> NODE: 192.168.1.11 <<
>> 40:1099511633885
>> >> NODE: 192.168.1.12 <<
>> 40:1099511633885
>>
>> [root at ceph ctdb]# /home/libnfs/examples/nfs-fh nfs://192.168.1.11//nfs-test-1.iso
>> 43000be210dd17000000010000feffffffffffffff000000
>> [root at ceph ctdb]# /home/libnfs/examples/nfs-fh nfs://192.168.1.12//nfs-test-1.iso
>> 43000be210dd17000000010000feffffffffffffff000000
>>
>> Now the file handle is identical.
>> Because the nfsv4 isn't supported by the CTDB, the mount option nfsvers=3 was used
>> when mount the nfs export on the client.
>
> So the problem occurs even with consistent file handles?  Hmmm...
>
> * Does the partial file exist in the cluster fileystem when the "stale
> file handle" message is printed?
>
> * Is the filesystem mounted after the failover?  Can you use "ls" to
> list a directory on the client?
>
> * What happens if you disable a node with "ctdb disable"?  Do you get a
> clean failover?
>
> Thanks...
>
> peace & happiness,
> martin