The two sides of reflink() [LWN.net]

The two sides of reflink()

Posted May 7, 2009 21:03 UTC (Thu) by anton (guest, #25547)
In reply to: The two sides of reflink() by martinfick
Parent article: The two sides of reflink()

For shared stuff like program text, all servers could use the same binaries (through mount, mount -t bind, or hard links), so that's not a good justification for reflinks, either (and if you don't trust the other servers not to write to the file, why would you trust them with access to the device at all?). Writable files that would mostly or completely be the same on both VMs would be a better example, but no concrete example comes to my mind.

(Log in to post comments)

The two sides of reflink()

Posted May 7, 2009 21:13 UTC (Thu) by martinfick (subscriber, #4455) [Link]

"why would you trust them with access to the device at all?"

You don't, usually the host system mounts a portion of the filesystem into a separate chroot for each guest server. The guests typically then have a limited root capability that does not included making device nodes so they really do not have access to the device, only the filesystem.

The two sides of reflink()

Posted May 10, 2009 18:42 UTC (Sun) by anton (guest, #25547) [Link]

The guests typically then have a limited root capability that does not included making device nodes so they really do not have access to the device, only the filesystem.

With the limits on the root capabilities, the binaries can surely be made read-only even for the guest roots, so no reflinks are needed for the binaries.

The two sides of reflink()

Posted May 10, 2009 19:09 UTC (Sun) by martinfick (subscriber, #4455) [Link]

The guests typically then have a limited root capability that does not included making device nodes so they really do not have access to the device, only the filesystem.
With the limits on the root capabilities, the binaries can surely be made read-only even for the guest roots, so no reflinks are needed for the binaries.

Sure, but if you make the binaries read only you no longer have independent guest systems that can be administered without knowledge of the host or other guests. In other words, if I now want to upgrade the apache server in one guest, I can't since the binary is read only to my guest root user. With COW, no problem, as a guest admin I do not even know that my apache binary is shared with others. It is only relevant to the host (the host unifies the various guest binaries, not the guest).