[Question] Simultaneous execution of sg_persist command and mount command.
HideoYamauchi opened this issue · comments
Hi everyone,
We use an agent called fence_scsi in a Linux cluster using the sg_persist command.
(https://github.com/ClusterLabs/fence-agents/blob/master/agents/scsi/fence_scsi.py)
This agent can operate in conjunction with the watchdog service, but if the device mount command and key acquisition by sg_persist overlap, the mount command may fail.
The problem seems to be that when the key acquisition by sg_persist is executed, the device accessed by sg_persist becomes invisible by mount command.
Is it possible for sg_persist to deal with this problem?
Or is the new sg_persist version solved this problem?
The problem can be reproduced by running the following script simultaneously.
Script 1.
#!/bin/sh
for i in {1..1000}; do
echo "### ${i} ###"
mount /dev/msa_b1 /dbfp/pgdata
if [ $? -ne 0 ]; then
break
fi
sleep 2
umount /dev/msa_b1
sleep 2
done;
Script 2.
#!/bin/sh
for i in {1..10000}; do
echo "### ${i} ###"
sg_persist -n -i -k -d /dev/msa_b
sleep 1
done;
The environment is as follows.
- RHEL8.0
- sg3_utils-libs-1.44-2.el8.x86_64
- sg3_utils-1.44-2.el8.x86_64
The key is registered in advance in /dev/msa_b.
Best Regards,
Hideo Yamauchi.
What type of device is /dev/mas_b1 ? If it is a block device, then I would try the corresponding pass-through instead (e.g. /dev/sg3 in Linux; /dev/pass2 in FreeBSD). To do a mount, you at least need to be able to read from the device. [Does the lock preclude reads?] If the mount is not read-only then it will probably set a dirty flag on the media. You are doing a read-only mount, aren't you (e.g. 'mount -r')? If the file system is mounted read-write, then first you should remount it read-only (e.g. 'mount -r -o remount / ' then take a persistent lock that allows reads.
Hi doug,
Thanks for your comment.
/dev/msa_b1 is a block device.
If this problem does not occur, the mount is successful and process can read and write.
A little different from usual is that this is access from vSphere (VMWare) guests.
I think the problem may be related to access via vSphere.
I have reported this issue to RHEL and are currently investigating it.
Best Regards,
Hideo Yamauchi.