On Thu, Mar 2, 2017 at 5:01 PM, Xiaoxi Chen <superdebuger@xxxxxxxxx> wrote:
> 2017-03-02 23:25 GMT+08:00 Ilya Dryomov <idryomov@xxxxxxxxx>:
>> On Thu, Mar 2, 2017 at 1:06 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote:
>>> On Thu, 2 Mar 2017, Xiaoxi Chen wrote:
>>>> >Still applies. Just create a Round Robin DNS record. The clients will
>>>> obtain a new monmap while they are connected to the cluster.
>>>> It works to some extent, but causing issue for "mount -a". We have such
>>>> deployment nowaday, a GTM(kinds of dns) record created with all MDS ips and
>>>> it works fine in terms of failover/ mount.
>>>>
>>>> But, user usually automation such mount by fstab and even, "mount -a " are
>>>> periodically called. With such DNS approach above, they will get mount point
>>>> busy message every time. Just due to mount.ceph resolve the DNS name to
>>>> another IP, and kernel client was feeling like you are trying to attach
>>>> another fs...
>>>
>>> The kernel client is (should be!) smart enough to tell that it is the same
>>> mount point and will share the superblock. If you see a problem here it's
>>> a bug.
>>
>> I think -EBUSY actually points out that the sharing code is working.
>>
>> The DNS name in fstab doesn't match the IPs it resolves to, so "mount
>> -a" attempts to mount. The kernel client tells that it's the same fs
>> and returns the existing super to the VFS. The VFS refuses the same
>> super on the same mount point...
>
> True,
> root@lvspuppetmaster-ng2-1209253:/mnt# mount -a
> mount error 16 = Device or resource busy
>
> Do we have any chane to make dynamic works(i.e suppress the -EBUSY
> for this case) for old kernel?
No, probably not. mount.ceph resolves DNS names, so you end up with
IPs in /proc/mounts which trick "mount -a" into attempting the mount.
Currently there is no way to tell mount.ceph to not resolve, and even
if there was, the in-kernel DNS resolver is disabled -- you'd need to
rebuild libceph and ceph kernel modules to enable it.
In your case -EBUSY most likely means that the filesystem is already
mounted, so it should be safe to ignore.
Thanks,
Ilya
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
