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