On Mon, Nov 26, 2018 at 03:00:41PM +0000, Alastair McKinstry wrote: > > On 26/11/2018 14:44, Adam Borowski wrote: > > On Mon, Nov 26, 2018 at 09:29:50AM -0500, Michael Stone wrote: > > > On Mon, Nov 26, 2018 at 03:08:09PM +0100, Marco d'Itri wrote: > > > > I disagree both that simple testing (that you could do with a KVM > > > > snapshot as well) would be hard and I disagree that the benefits of > > > > merged-/usr would be minor. > > > Nobody has thus far pointed out a single benefit to someone merging usr on > > > an ordinary system. > > Nor for clusters, for that matter. I don't get how having the /usr part of > > the filesystem (no /var, /lib, /etc, etc) would help -- > > Moving config from /etc to below /usr becomes useful for containers, and > hence clusters.
... well, how? > containers become important for clusters - we are now using Singularity in > our HPC clusters. Singularity is a development of Docker that allows for > non-root container execution; we can build containers on our laptops, etc > (requiring root), and copy them to the cluster, where they will run, even > connecting with mpiexec / slurm ,etc You still need all the rest of the files. There might be cases where making them volatile and copying from a base state to tmpfs on every boot could be workable, but that's a pretty odd setup -- which is handled just as well by more generic solutions. So why won't you use any of the many ways you pruned from my post you responded to? > Now, we can build a container on a laptop, with Debian inside, and run it on > a 1000-node cluster. Its realistic to see million-core jobs on Debian in > the future. So you propose to make that cluster have every node be more resource contrained than the weakest Debian-capable SoC / phone available in the wild? The vast majority of non-GUI installs I've seen have /usr of below 1GB, with available storage massively larger than that. So any realistic HPC cluster will have many orders of magnitude more space, per node -- making even deduplication a waste of human time. If there's indeed no storage per-node, please don't insult our intelligence by suggesting having the central server keep that /usr shared would require a non-laughable effort. And if it does... well, please read the list of solutions I mentioned. I quite recently worked with multi-container hosting -- there's no problem with deduplication using already existing tools. And in hindsight, it was a waste of my time -- it's customers' data that takes space, not /usr. > So, while supporting containers may support a minority of users, I suspect > some will be big users, and as library and app complexity grows, its an > important Debian use-case. Yes, it's an important use-case. And one already solved without merging /usr. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC? ⠈⠳⣄⠀⠀⠀⠀