[Question] Simultaneous execution of sg_persist command and mount command.

[HideoYamauchi]

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.

[doug-gilbert]

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.

[HideoYamauchi]

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.