Le 05/01/2016 20:25, Rob Owens a écrit :
----- Original Message -----
From: "Didier Kryn" <k...@in2p3.fr>
Le 05/01/2016 15:59, Rob Owens a écrit :
I have customers who use a shared /usr among several zLinux
systems, and the reason is cost savings.
For my information: They don't share rootfs? How do they manage
package upgrade?
I just spoke to some coworkers and I have to revise my story a bit. The
short answer is I don't know if these particular customers share the entire
rootfs, just /usr, or some subset of /usr.
There are mainframes that are used to host thousands of zLinux systems.
For example, they may provide web servers to customers. In this
scenario, they will attempt to share as much disk as possible between
systems. The shared disk will typically be read-only on all systems except
for one (perhaps a management system which is used to perform updates).
Each system of course needs some read-write space, but the more shared
disk it can utilize, the better (because that is cheaper and easier to
manage).
So are they sharing /usr and owning individual root filesystems? I'm
not sure what these particular customers are doing. I can imagine
scenarios where having that ability would be beneficial, but I'm not
sure if these customers are actually doing it. I do know that they make
heavy use of read-only disk sharing, and that taking two separate
directories and dumping them into one will reduce granularity, which can
make it more difficult to optimize disk sharing.
-Rob
I have installed farms of diskless single-board computers. Each
group shares the Debian Wheezy OS installed on an NFS server. Most files
and directories must be shared but some must not: /run and parts of
/var/lib. It is delicate and tricky to craft which subdirectory of
/var/lib is shared and which is not.
/etc/resolv.conf is symlinked to a file in /run which is created
during the initramfs step. In principle resolv.conf could be shared
because they are all in the same LAN, but this configuration avoids
overwriting continuously the same file.
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
