Recursively creating hard-links to files in the parent vserver's directory tree and running 'setattr --iunlink <file_name>' does seem to be the most straightforward solution to rapidly cloning a vserver. This approach has the added benefit (I think) of supporting making copies of vservers that are themselves copies of other vservers (since multiple instances of the same file would point to the same inode, COW should behave correctly; am I correct here?).
However, I was hoping to be able to clone vservers in a single operation instead of having to traverse the directory tree. As an alternative solution, has anyone tried using unionfs to create clones of vservers? Unionfs may also be able to support quickly creating clones of clones. However, I'm conerned that the performance of unionfs may degrade as the number of layers used increases. http://www.unionfs.org discusses performance degradtion (vs native ext3) of up to 12%. Also, I'm not sure whether the UnionFS kernel patch is compatible with Vserver-devel. I'm also considering using some combination of BME and COW. Does anyone know whether it's possible for me to 'clone' a vserver by bind-mounting the parent vserver and using COW to incrementally create copies of the parent vserver's files as they are accessed by the child? Is there any limit to the number of bind-mounts I can have on a single vserver-patched system? Thanks. On 6/3/06, Grzegorz Nosek <[EMAIL PROTECTED]> wrote:
2006/6/3, Bruno <[EMAIL PROTECTED]>: > I don't know if vhashify and friends of util-vserver keep some state of their > operations (like a DB of hashed files) AFAIK they just store files in a directory tree with their sha1 hashes as file names > > What may be useful is e.g. an adjusted 'cp' tool that copies regular files as > hardlink to the reference and adds IUNLINK and IMMUTABLE flags to the > hardlinked files (where the flags are not alreay present) > This will copy a whole guest as quickly as scanning the existing tree and > creating a new inode/hardlink for each inode encountered. A neat addition might be automatically differentiating between unified files (hardlink them with cow flags) and normal files (copy them over) so that copying an already vhashified vserver would be a single command Best regards, Grzegorz Nosek _______________________________________________ Vserver mailing list [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________ Vserver mailing list [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
