We've been sharing /usr (and sometimes /opt) for about three years on SLES7 and SLES8. It works very well.
The only area you have to be careful about is when you add service or upgrades to your images. Adding service or upgrade .rpm's for a product usually means that files get updated on /usr and also in non-/usr areas. If /usr is shared read-only, that means you can't run the rpm on each and every image. You have to run it on some central image that owns /usr. And if you change a disk that other systems access read-only, the other systems will give errors thinking the disk is corrupted, and you won't see the new files until it's remounted anyway, which you probably can't do while the system is running. We are currently using two full-pack 3390-3's for production and upgrade versions of /usr and toggle between them. But that doesn't get all the files. You'll have to copy over all the files that aren't in /usr to each and every image, shut down the image, re-link the disk that points to /usr and reboot. This is turning out to be a lot of trouble just to save some disk space when you have dozens of images. You have to ask yourself, "Is the extra labor involved in the maintenance process justified in light of how cheap disk storage is?" Add to that the fact that many of my customers don't want their Linux server to be taken down for service upgrades and the problem compounds itself. There are companies that sell maintenance solutions that take care of these problems, like Levanta and Aduva. They aren't cheap and they use a lot of system resources. We were evaluating Levanta when management killed it because of cost. Of course, at that time our stock price was about half of what it is now and management was watching every penny. We are actually thinking about going back to a configuration where everything is read-write. Disk is cheap and labor for maintenance isn't. Then we could link to a central NFS server where the rpms are stored and use ssh from a central point to load the service from rpm. "Nature and nature's laws lay hid in night: God said, 'Let Newton Be!' and all was light." - Alexander Pope "It did not last; the Devil howling 'Ho! Let Einstein Be!' restored the status quo." - John Collings Squire "God Rolled his dice, to Einstein's great dismay: 'Let Feynman Be!' and all was clear as day." - Jagdish Mehra Gordon W. Wolfe, Ph. D. VM Technical Services, The Boeing Company > ---------- > From: Richard Troth > Reply To: Linux on 390 Port > Sent: Thursday, May 20, 2004 7:47 AM > To: [EMAIL PROTECTED] > Subject: Re: Linux file Shareing > > > Does anyone have any experience with Linux File Shareing? > > I do it all the time! > > > When is it best to do Linux File Shareing? > > Things that are clearly read-only are the immediate candidates. > Sharing by way of VM minidisks requires read-only operation. > > > What kinds of things should be looked at before we go with File Shareing? > > Deployment after sharing has begun (or generally any admin > or maint after sharing has begun) is probably the biggest pain point. > > > We are thinking of doing some fileshareing with the /usr directory > > structure where we have installed Oracle and share that ... > > Sun set a precedent for sharing /usr more than a decade ago. > Linux has been slow to pick-up on the idea (because most Linux > systems are on independent PC class machines). Sun uses NFS. > Now with zSeries Linux running on VM, there is physical (appears > to Linux) sharing of the underlying device, which Sun did not have. > Now with SAN, Sun can enjoy sharing physical devices too! > For that matter, non-mainframe Linux can share volumes (on SAN). > > /usr and /opt are the most immediately obvious choices. > The root can be difficult, but your /etc and /var content are > even more difficult than a shared root FS. (/boot is generally> > sharable if you split it from the root; I do.) > > -- R; > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
