Hi all
I am planning on using vservers for an upcoming project and I have been
doing extensive checking that I can achieve my objectives.
So far so good - I am very impressed.
I have come across something strange (= did not do what I expected).
First the scenario:
A disc contains an ext3 filesystem and is mounted rw on /X
The top level is:
/X/DIR
/X/HASH
/X/HASHES
/X/RO
The contents of DIR has been hashified and the hashes are in HASHES.
/X/DIR is then bind mounted ro on /X/RO
This works 100% as I expect - I can mount /X/RO during the vserver
initialize script and I have an ro version of the data for the vserver
to use. Good.
To give each vserver a rw version of /X/DIR without disturbing all the
other vservers I use aufs.
The ro branch of aufs is /X/RO and the rw branch is outside the vserver
client tree. (i.e. the vserver has no direct access to it).
The aufs mount is done in the initialize script at the same point where
in the previous test I bind mounted /X/RO.
This work 99% as I expect. The vserver can use the filesystem in rw mode
and it is independent of other vservers.
The one exception is if I try to hardlink a file which has been
hashified. I expected the kernel to break the hardlink to the hash and
give me a fresh copy of the file and then hardlink to that. Instead I
get EPERM.
If I touch the file it does in fact break the hardlink to the hash and I
can then hardlink the file I have just touched.
This is all well and good if I am doing this in a script in the vserver
but some programs (Debian's dpkg for example) use hardlinking in their
logic.
Is this a bug? Is it an enhancement? Is it because of aufs?
Is there any reason why the kernel cannot treat the link system call the
same way as changing the file metadata by touching the file?
This is not a major obstacle to further development of my project but it
would be nice if I had a solution. Maybe there is a solution using lvm
and snapshots but for all I know I will hit the same problem there.
I have many other tests to do and I can revisit giving guests rw
versions of a common filesystem later.
Thanks to all involved in vservers.
Allan
Received on Wed May 1 11:14:02 2013