On Fri, Sep 10, 2004 at 12:16:33PM -0700, Wolfe, Gordon W wrote:
> This is one possible architecture.  Whether it's recommended or not depends on why 
> you want to do it.
> 
> The advantages are 
> 1) saving disk space.  Depending on how expensive dasd is in your organization, this 
> can be considerable.
> 2) Allowing minidisk cacheing to take place, reducing the number of physical I/O's 
> and speeding up response.  
> 3) keeping your users from installing programs or making modifications on their own 
> and then calling you at three in the morning when their server goes down.  then you 
> find out after two hours of work that the problem is some modification they made.
> 4) Creating a "standard" version of Linux that is easily deployable.
> 
> The disadvantages are:
> 1)  Service is much more difficult.  You have to install updates on a test server, 
> then compare before and after with tripwire to see what files were updated on /usr 
> and which were not.  You have to route the non-/usr files around then swap /usr 
> disks and reboot.  You end up having almost as many /usr disks with different 
> versions on them than you would have if everybody just had their own disk.  I've got 
> 38 servers and 6 different shared /usr disks, not to mention 4 or 5 servers with 
> non-shared /usr.

This ist true for a real disk. If you use DCSS in VM than VM takes of running the right
Version for your Linux client. Then you do not need to shut down all client at one 
point
in time, but one after the other.

DCSS also saves a lot of I/O. If you share a disk, each linux client still
generates I/O. With DCSS only the first linux client generates the I/O,
the second just reference the same memory location.

Have a look at http://oss.software.ibm.com/linux390/docu/lx26dcss00.pdf

This explains DCSS in connection with linux detail.

Regards

Ihno


> 2) you have altercations with users who want to write to the /usr disk.  Usually you 
> can get around it by loop-mounting a subdirectory in /home over a /usr subdirectory. 
>  Installing WebSphere with a read-only /usr is virtually impossible, as are other 
> program products.
> 
> I'd say if all of your linux servers are essentially identical, shared /usr makes a 
> lot of sense.  If they are all configured differently, question it.
> 
> We've been using shared /usr for about three years.  We are considering going to 
> individual read-write /usr areas with SLES9, just for the ease in maintenance.  Disk 
> is cheap here.  We bill our customers only $6.14 per gigabyte per month for 3390 
> dasd storage. A full-pack 3390-3 for /usr is about 80% full and is about 2.2GB.
> 
> Check out my presentation at SHARE on this topic at 
> http://linuxvm.org/present/SHARE101/S9343GWa.pdf
> 
> So one elephant says to another, "You'll never believe what happened last night. I 
> was trying on Groucho Marx's pajamas--and he shot me!" 
> Gordon Wolfe, Ph.D. (425)865-5940
> VM Technical Services, The Boeing Company
> 
> > ----------
> > From:         Doug Griswold
> > Reply To:     Linux on 390 Port
> > Sent:         Friday, September 10, 2004 11:24 AM
> > To:   [EMAIL PROTECTED]
> > Subject:      Shared /usr
> > 
> > I have a question about sharing /usr with multiple vm guests.  Is this a
> > recommended acrchitecture?  Are there any benefits to doing this other
> > than saving space.  It seems to me this could be problematic when
> > applying fixes from yast.  I welcome any input on this subject.
> > 
> > 
> > 
> > Thanks,
> > Doug
> > 
> > ----------------------------------------------------------------------
> > 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

-- 
Best regards/Mit freundlichen Gr��en

Ihno Krumreich

"Never trust a computer you can lift."
--
Ihno Krumreich            [EMAIL PROTECTED]
SuSE Linux AG             Projectmanager S390 & zSeries
Maxfeldstr. 5             +49-911-74053-439
D-90409 N�rnberg          http://www.suse.de

----------------------------------------------------------------------
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

Reply via email to