The two sides of reflink()
The two sides of reflink()
Posted May 10, 2009 18:42 UTC (Sun) by anton (subscriber, #25547)In reply to: The two sides of reflink() by martinfick
Parent article: The two sides of reflink()
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.
Posted May 10, 2009 19:09 UTC (Sun)
by martinfick (subscriber, #4455)
[Link]
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).
The two sides of reflink()
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.