This has nothing to do with the block storage underneath. The same would happen with any other storage. It has everything to do with the filesystem you are using on both hosts.
For any host to be able to read/write to a volume that is mounted on more than one host AND have the other hosts read/write to the same files/directories (without a dismount), you need a cluster filesystem. ESXi uses VMFS, which is a clustered filesystem. Each host communicates to the other thru various means to let them know they have a lock/reservation and to not touch that particular file when it's open, while sharing the metadata as well to each host.
For Linux, you can try ocfs2, gfs2, GlusterFS, etc. There are a few to choose from. Good luck
But I dont understand... I mapped same volume to two SDC. If I read binary data from block device (/dev/scinia) on both SDC, and change it (with dd), I see changes only on SDC where I did that. Reading data from scinia on other SDC returns old data. Results must be same, isn't?
Similar effect I see when using clustered filesystems...
What are describing is exactly the symptoms you would see if you are not using a clustered filesystem. A host does not constantly scan a device for changes made at the block level. That is what the filesystem is for, to be aware of changes made and let the host know. If host A creates a file, how is host B made aware that this file now exists, except that the filesystem is made aware. The only time a rescan happens is on boot or remount of the disk itself, which is why you see if after a remount.
Doing what you are doing now is a good way to corrupt the data on the disk, as the hosts sharing the disk are not aware of each other.
Here are a couple links I found with a quick search:
If you are seeing the same effect when using a clustered filesystem, I would venture to guess that something is not configured properly on the cluster or the filesystem.
RHasleton1
73 Posts
1
October 26th, 2017 07:00
Hi Sam,
This has nothing to do with the block storage underneath. The same would happen with any other storage. It has everything to do with the filesystem you are using on both hosts.
For any host to be able to read/write to a volume that is mounted on more than one host AND have the other hosts read/write to the same files/directories (without a dismount), you need a cluster filesystem. ESXi uses VMFS, which is a clustered filesystem. Each host communicates to the other thru various means to let them know they have a lock/reservation and to not touch that particular file when it's open, while sharing the metadata as well to each host.
For Linux, you can try ocfs2, gfs2, GlusterFS, etc. There are a few to choose from. Good luck
Rick
glhf
6 Posts
0
November 2nd, 2017 04:00
Thank you for your answer!
But I dont understand... I mapped same volume to two SDC. If I read binary data from block device (/dev/scinia) on both SDC, and change it (with dd), I see changes only on SDC where I did that. Reading data from scinia on other SDC returns old data. Results must be same, isn't?
Similar effect I see when using clustered filesystems...
RHasleton1
73 Posts
0
November 2nd, 2017 07:00
Sam,
What are describing is exactly the symptoms you would see if you are not using a clustered filesystem. A host does not constantly scan a device for changes made at the block level. That is what the filesystem is for, to be aware of changes made and let the host know. If host A creates a file, how is host B made aware that this file now exists, except that the filesystem is made aware. The only time a rescan happens is on boot or remount of the disk itself, which is why you see if after a remount.
Doing what you are doing now is a good way to corrupt the data on the disk, as the hosts sharing the disk are not aware of each other.
Here are a couple links I found with a quick search:
storage area network - Why are two servers viewing the same drive unable to view the same files? - Server Fault
https://en.wikipedia.org/wiki/Clustered_file_system
If you are seeing the same effect when using a clustered filesystem, I would venture to guess that something is not configured properly on the cluster or the filesystem.
Good luck,
Rick