3

Is there any file system that can be mounted multiple times and supports concurrent file access for Linux? Basically I want something like a cluster file system but without the need to have a running network for a distributed lock manager. That can be very handy in connection with virtual machines that can share data with the host or another VM without the need to create a network link. This I want to avoid to keep the network architecture secure (virtual machine in DMZ) but share large files. No need to scale it up, just two machines that mount the same block device.

Shouldn't it be possible to have file locking information right on the disk?

fungs
  • 61
  • 3
  • How are the machines access the shared storage without networking? As an aside, if you're avoiding networking because you think there are inherent security risks you should probably call in a networking/security expert to configure the machines properly. – Chris S Nov 18 '11 at 16:56
  • You really can't have a (working) cluster file system without a lock manager. However, the lock manager nodes do not necessarily need to communicate over the network - they could use the shared storage for communications as well. I believe GFS2 does have a lock manager with networked communications, though. No idea if other freely available file systems will do differently. – the-wabbit Nov 19 '11 at 22:54
  • @Chris: XEN supports accessing LVM devices directly. This is definitely more secure than using networking if you want share files between a VM in the DMZ and another VM in a trusted internal network. This is a deeper sandboxing approach. – fungs Nov 29 '11 at 13:31
  • @syneticon-dj: yes I am looking for some file system that supports locking via the shared block device (or some other block device). – fungs Nov 29 '11 at 13:33

2 Answers2

0

I would guess that you can give N VMs and access to the same block device but only read only. You note that word guess.

Things will fall over quickly if any of the VMs start modifying things since any disk caching the other VMs will now be invalid.

The difficulty in having file locking information on disk is that no one has done that yet. Without deep thought, the idea of an atomic read/modify/write transaction on a disk is probably the base problem.

I guess that you could take a typical file system that is already multi-threaded, figure out where the lock(s) is/are used and change that to some sort of read/modify/write operation on the disk.

The other problem with read/modify/write on the disk is that if you do a lot of locking, your performance will be pretty bad since every change to anything on the disk requires:

  • lock the disk (seek, read/modify/write)
  • read the sector you want to change (seek/read)
  • make the change and write (write)
  • unlock the disk (seek, read/modify/write)

It probably doesn't help, but I would look at something like BSD Jails as a more lightweight VM system if you really don't want networking up.

Bruce ONeel
  • 401
  • 2
  • 1
  • Performance shouldn't be of an issue. I could also imagine putting a virtual block device file under /dev/shm/locking_device and using that for locking.I am just disappointed that nobody uses raw locks on some file system level instead of networking because it could be so useful in the VM case. – fungs Nov 29 '11 at 13:39
0

To give an answer to my own question: in the situation of (para)virtualization there are some shared file systems evolving that can be used to share file without network between instances. XenFS is one approach not actively under development, I think. But for KVM, and hopefully for XEN soon, there is a folder sharing mechanism based on the virtio library called 9p_virtio.

fungs
  • 61
  • 3