The question I posed was whether there were compelling reasons to use
Digital's advfs for the OS partitions. The question was never whether
advfs was a good solution for arbitrary data, rather the narrower
question dealing with the Digital Unix partitions.
My system administration experience is from spending many years dealing
with Sun's platforms; i.e., SunOS and Solaris. My only Unix non-UFS
experience is dealing with AIX's jfs and limited playing with veritas
software.
I received many contradictory recommendations both strongly for and
decidedly against. Some, were based on antidotal evidence, fear,
uncertainty and doubt driven by no small measure by Digital's past
mistakes. There were some good points made about healthy skepticism
dealing with vendor's claims and some first hand disaster stories. On
the other hand, many people responded with years of positive experience.
Based on the feedback I received and my personal biases, my
recommendation would be to not use advfs for the Digital Unix OS
partitions. I think that people which are extremely conformable with the
technology, feel that advantages are compelling, and believe that the
added complexity is negligible, are missing two points. First, added
complexity during disaster recovery is almost always a bad thing.
Secondly, a sysadmin is routinely not around during the entire lifecycle
of a box. It is often handed off to another person. Even if the person
doing the install was extremely knowledgeable about Digital Unix and
advfs, then other person is likely to be.
Imagine being a sysadmin of 20 machines (17 Solaris, 3 Digital Unix).
You've read the advfs man pages, and you've dinked around. One of the
Digital machines goes down. Was it really worth the advfs to perhaps
grow the /usr partition compared with the extra time it takes to bring
back the server? My experience says that it wasn't. But it's just my
opinion.
Here are some of the advantages of using advfs for the OS partitions:
---------------------------------------------------------------------
1) Many people point out that advfs is Digital's direction for file
systems and will be the basis of new cluster technology in version 5.x
2) Advfs, being a transactional filesystem, is much faster doing a
rollback or commit during boot than a traditional fsck. However, even a
full fsck of /, /usr, and /var doesn't take that long on modern
hardware. A 43 GIG data drive on the other hand...
3) Advfs, being a transactional filesystem, is less likely to permit a
inconsistent filesystem thereby reducing that opportunity for corrupt
filesystems. However, since / and /usr shouldn't have many open files
(/var should be a separate filesystem), traditional filesystem don't
tend to corrupt that easily either. If the advantage is based on better
and faster recovery after unexpected power outages, then the solution is
not a better filesystem, rather a UPS, etc...
4) Given enough disk space you can use the cloneset feature to make
online backups
Here are some of the disadvantages of using advfs for the OS partitions:
------------------------------------------------------------------------
1) Added complexity during the most stressful time: disaster recovery
2) Even though most advfs bugs appear to be fixed in 4.0D+patches, not
everyone can run the latest and greatest. Also, it has taken a
considerable time to get to this point, and it will be some time before
we know this to be true
3) UFS deals with marginal hardware better than Advfs.
4) UFS can be faster. However, this is a marginal issue with the low i/o
needs of an OS partition.
5) Additional memory is used in the buffer cache for advfs which has to
be at least %1.
BTW, I mistakenly stated earlier that I believe that advfs had to be
removed during an OS upgrade. Many people pointed out this is an
outright falsehood. During the upgrade, the advfs utilities are removed
to prepare for the new versions.
Thanks for all the comments from:
J. Dean Brock <brock_at_cs.unca.edu>
John Speno <speno_at_isc.upenn.edu>
Stephen Dowdy <dowdy_at_cs.colorado.edu>
Allan J. SIMEONE <Allan.SIMEONE_at_rp-rorer.com>
Randall R. Cable <randy.cable_at_mci.com>
Roy Smith <roy_at_popmail.med.nyu.edu>
J. Dean Brock <brock_at_cs.unca.edu>
<alan_at_nabeth.cxo.dec.com>
Tom Webster <webster_at_ssdpdc.lgb.cal.boeing.com>
Thomas Leitner <tom_at_finwds01.tu-graz.ac.at>
Peter Stern [peter_at_wiscpa.weizmann.ac.il>
Ansgar Schlueter <Ansgar.Schlueter_at_iabg.de>
Christophe DIARRA <diarra_at_ipno.in2p3.fr>
Ed Lewis <ELewis_at_RBMG.com>
Chris Ruhnke <i769646_at_SMRS013A.MDC.COM>
Mark Ray <Caprica7_at_aol.com>
Christopher Knorr <cknorr_at_hops.com>
Dr. Tom Blinn <tpb_at_doctor.zk3.dec.com>
Eskil Swahn <Eskil.Swahn_at_LDC.lu.se>
Stephen Mullin <Stephen.Mullin_at_gecits.ge.com>
Bruce Kelly <kellybe_at_llnl.gov>
Ram Rao <alphaosf_at_ini.dec.com>
Tony Miller <anthony.miller_at_vf.vodafone.co.uk>
Richard L Jackson Jr <rjackson_at_portal.gmu.edu>
Received on Thu Jan 14 1999 - 16:25:08 NZDT