Re: usrmerge -- plan B?
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?
⠈⠳⣄⠀⠀⠀⠀
Reply to: