4 ms·

But the linker doesn't try to keep code in a dedupe friendly format. I don't think this would help on a pile of Go/rust binaries. Maybe there would be better s

by tln 6y ago

But the linker doesn't try to keep code in a dedupe friendly format. I don't think this would help on a pile of Go/rust binaries. Maybe there would be better sharing if I extracted the ELF sections first. I just ran an experiment on the 20 largest items in my Mac's /usr/local/bin, many of which are Go binaries for file in `find /usr/local/bin -perm +u+x | xargs ls -SL | head -20`; do split -a4 -b4k $file `basename $file`; done ls | xargs md5 > md5.txt cut -d' ' -f4 md5.txt | sort | uniq -c | cut -c1-4 | sort | uniq -c This gives: (number of 4kb blocks, frequency of sharing) 128021 1 12105 2 13 3 1 4 1 1137 so about 10% of blocks are shared... once. And 1 blocks is shared 1137 (all zeroes). To your second point, we still want fast security updates and more secure code even with sandboxing! EG, sandboxing would not help with heartbleed -- critical data leaked.

SigmundA 6y ago
System wide shared libs is the opposite were we are trying to optimize space at the file level rather than block, and the linker instead optimizes for that along with all the other baggage of shared libs. So if block level dedupe where the norm linkers would optimize for that instead. Coming from the .Net / Node world you don't statically link but you typically don't have shared libs, all the libs are in the same folder as the executable and dedupe works just fine there because you have just a bunch of duplicated files in different directories. Same with containers and Vm's all duplicating a bunch of the same system files. You get isolation and reuse because its done at a lower abstraction. As far as security, again my point was a trade off, yes you could potentially get security updates faster along with breaking changes faster. If the sandbox apps had a good way to stay up to date, then they can update upstream after being integrated and tested with the app. If you have an app store of some sort it can watch for and notify to the authors of security issues in libs these use and prompt them to upgrade or be taken down. I know the app store argument probably isn't popular around here but from my experience it is a far more secure solution especially for the non technical user. If something is really so widely used it should be a api provided by the OS, otherwise it should be bundled with the app individually and code sharing is done in source repos / build systems, at least thats my opinion after all these years.
- cyphar 6y ago
  > Same with containers and Vm's all duplicating a bunch of the same system files. You get isolation and reuse because its done at a lower abstraction. Deduplication of containers is incredibly coarse-grained -- it's done a whole-layer basis which means that an update to any distribution package in a base image (resulting in a new layer hash when you rebuild on top of it) results in zero sharing between containers based on different versions of the base image. I am actually trying to rectify this problem with the whole OCIv2 effort -- but I wouldn't argue that today's containers make this problem non-existent. To be honest I hesitate to call the current model "deduplication" at all (yes, it might technically be deduplicated but it's not doing it to the degree you think it is). And note that the page cache sharing you get from containers is also on the file level, so it's strictly no better than shared libraries (since the container filesystems contain shared libraries and that's what's being shared through the page cache).

by tln 6y ago

SigmundA 6y ago

System wide shared libs is the opposite were we are trying to optimize space at the file level rather than block, and the linker instead optimizes for that along with all the other baggage of shared libs. So if block level dedupe where the norm linkers would optimize for that instead. Coming from the .Net / Node world you don't statically link but you typically don't have shared libs, all the libs are in the same folder as the executable and dedupe works just fine there because you have just a bunch of duplicated files in different directories. Same with containers and Vm's all duplicating a bunch of the same system files. You get isolation and reuse because its done at a lower abstraction. As far as security, again my point was a trade off, yes you could potentially get security updates faster along with breaking changes faster. If the sandbox apps had a good way to stay up to date, then they can update upstream after being integrated and tested with the app. If you have an app store of some sort it can watch for and notify to the authors of security issues in libs these use and prompt them to upgrade or be taken down. I know the app store argument probably isn't popular around here but from my experience it is a far more secure solution especially for the non technical user. If something is really so widely used it should be a api provided by the OS, otherwise it should be bundled with the app individually and code sharing is done in source repos / build systems, at least thats my opinion after all these years.

cyphar 6y ago
> Same with containers and Vm's all duplicating a bunch of the same system files. You get isolation and reuse because its done at a lower abstraction. Deduplication of containers is incredibly coarse-grained -- it's done a whole-layer basis which means that an update to any distribution package in a base image (resulting in a new layer hash when you rebuild on top of it) results in zero sharing between containers based on different versions of the base image. I am actually trying to rectify this problem with the whole OCIv2 effort -- but I wouldn't argue that today's containers make this problem non-existent. To be honest I hesitate to call the current model "deduplication" at all (yes, it might technically be deduplicated but it's not doing it to the degree you think it is). And note that the page cache sharing you get from containers is also on the file level, so it's strictly no better than shared libraries (since the container filesystems contain shared libraries and that's what's being shared through the page cache).