[lxc-users] mounting the same path on multiple containers

[Werner Hack]

Maybe I have not expressed myself clearly.
I want to add the same data directory to multiple containers (bind mount).
The data is stored in a zfs pool if this is relevant to my question.

Now, we presume there are two independant users (or services) working on two different containers.
They are editing the same file on the common data storage at the same time.
Can this corrupt my filesystem or is this managed by the host (or kernel or whatever) correctly?
Could this be a problem and I damage my filesystem this way?

Thanks in advance
Werner Hack


On 04/20/2017 03:37 PM, T.C 吳天健 wrote:
> I think lxc just do bind mount for you.  It will or not damage file depends on the device file
> nature.  For example, block device allows multiple process read-write.  Some other drive file
> might not allow multiple entry.
>
> 2017年4月20日 下午9:21，"Werner Hack" <werner.hack at uni-ulm.de <mailto:werner.hack at uni-ulm.de>>寫道：
>
>     Hi all,
>
>     I want to mount (lxc device add) the same path on multiple containers.
>     Is this possible or will I damage my filesystem this way?
>     How is concurrent (write) access to the same directory from multiple containers handled?
>     Is this managed with lxd daemon or the kernel and I have not to worry about it?
>     Or have I to use a cluster filesystem in this case?
>
>     Thanks in advance
>     Werner Hack
>
>
>     _______________________________________________
>     lxc-users mailing list
>     lxc-users at lists.linuxcontainers.org <mailto:lxc-users at lists.linuxcontainers.org>
>     http://lists.linuxcontainers.org/listinfo/lxc-users
>     <http://lists.linuxcontainers.org/listinfo/lxc-users>
>
>
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170421/2c51f03d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20170421/2c51f03d/attachment.bin>