SUMMARY: After your opinion: VxFs v ufs+logging & Disk-suite

From: Miller, Anthony, A, Tech Dev, VF UK <>
Date: Thu Aug 22 2002 - 03:25:43 EDT

Some weeks ago I circulated a request for your opinions on VxVm/VxFs/UFS/SDA

Thanks to everybody who replied including:

Rachel Polanskis []
Todd M. Wilkinson []
Simon-Bernard Drolet []
Kevin Buterbaugh []
Jeff Kennedy []
BAUMLER Julie L []
Lee, Elizabeth []
King, Brooke []
Karl Vogel []
Broun, Bevan []
John Eisenschmidt []
Bob Smith []

I must also thank Karl for some general tuning/performance tips.

Its kinda hard to summarise actually because everybody said loads of
interesting stuff.  basically I have hacked in peoples comments roughly into
some relevant sections below.  Probably best just to read it all if you are
interested and make up your own mind.

Thanks everybody.

best regards - T

|    Team Leader : Technical Projects,
|                  VODAFONE LTD,
|                  Derby  House,
|                  Newbury Business Park,
|                  Newbury, Berkshire.
|    Phone        +44 (0)1635-677687(local)
|    Email
|    FAX          +44 (0)1635-233517

I would not have Veritas controlling my boot disks. I would be wanting to
stick with something the Solaris install CD can understand.

*	UFS+ logging for Boot system disk
*	VxVM for application file systems
Why ? for the first case, it's rather easy to un-mirror and un-encapsulate a
UFS + logging a boot system disks
and the action should be performed more often on a system disks than on
application disks
UFS is free and allows very fast and simple system management

VxVm is application oriented and its GUI is very powerful and provides
pertinent informations.
Also, for application operation, for example, if I want to migrate datas
from an EMCbay to another one,
I can simply mirror one bay to another one with VxVm, very simply and after
cut the link between the two bays.  This is the easiest way and VxVm fits tho
our needs

Recommend using Disksuite on the boot volumes
due to it's simpler recovery process.  VxVm used on data volumes
or where there are large numbers of disks involved.  Veritas give better
support for multi disk set-ups with multiple controllers as well.
Disksuite is better for simple set-ups where only a few disks are involved.

VxVm - don't use vxupgrade scripts as these are unreliable.  Unencapsulate by
hand etc and re-encapsulate/mirror after upgrade.

We use VxVm everywhere - The new release of SVM in Sol9 and the patched
version in the  last release of Sol 8 they keep private regions on the disk
rather than on a database making the use of SVM a better option in the future.
We are looking at using SVM for mirroring the root disk for appliance like
boxes with little system data ( DNS servers, load balanced web server etc. ).

we've (I) decided that it is easier to have a standard root/boot disk set-up,
so we always use SVM+UFS+logging to mirror the boot disks.  On top of that, if
we have more than 20 disks, or we use a cluster software or we need support
24/7, then we add VxVM+VXFS on the server.  The point here is that the system
disks on a simple server like a netra T1 with two disks or a SF3800 with two
disks, will have the same layout.

I know a lot of sites that use SVM for mirroring the OS and VxVM for
everything else.  That's because encapsulating the root disk is a pain
compared to mirroring with SVM (especially dealing with a failed disk / OS
upgrade).  we've found that SVM, especially in conjunction with UFS logging,
gives us an adequate level of performance.  Management is simpler, since
you're only dealing with one volume manager instead of two.  And, as you've
already noted, SVM is free while VxVM is big bucks.

My answer would be this, use Solaris 9 and scratch Veritas where possible.
The new volume manager in Solaris 9 looks great, does 90% of what VxVM will
do, and for free.

This is similar to the problems we are wrestling with.  I am a huge fan of
VxVM but the lack of integration into Solaris definitely causes problems.
More than the upgrade issues, the fact that you have to do special work to
safely install a kernel patch on a system that has a VxVM encapsulated root
file system is miserable.  The fact that you need 2 spare partitions to
install VxVM on your root disk is also a problem for me, now that management
is buying us 20-36GB root drives.

Last year, I spoke with some of the Veritas engineers about the kernel
patching issue and was told that in the next major release of VxVM, you
wouldn't be required to have a rootdg.  This would mean that you could
unencapsulate root without removing VxVM, which solves both the patch and
the upgrade problems.  It also means that you will be able to use Disksuite
for mirroring your root partitions (which is well integrated into the OS)
and use VxVM for the data partitions and still be able to move your data
volume groups to another system (some people work around the current
situation by putting their data, not their root, in rootvg).  My plan was to
transition to a situation where this is our default configuration.  In the
meantime, I am continuing to run VxVM on all the systems that had it
already.  I have started using Disksuite on new systems, as long as I can
meet my customer's needs.  Apparently there are tools to allow you to
convert SDS partitions to VxVM partitions, but this is really only an issue
if you are using software RAIDS, so I haven't fully investigated it.  I am
by no means an expert in DiskSuite, but knowing what a volume manager can do
has made it very easy for me to find the commands I need to run to meet my
needs.  I've been impressed with DiskSuite over the last year, and our
already project/customer oriented environment has become more so in that
time period; we are talking about moving to an environment where customers
(projects) can choose not to pay for the cost of an extra disk to mirror
their root disks (some people have already doing this against our will by
going above us), but then agree to non-priority restores (i.e.. We only
restore during our regular working day and if a RAIDed customer loses data,
the later gets priority.); I suspect that we will start offering the choice
of SDS/VxVm/both on a cost basis.  We also support AIX (and therefore LVM);
I find that my co-workers who are comfortable with the concepts of volume
management have no problem administering multiple volume manager software,
those who are confused by the concepts need a cookbook approach to most
tasks, since the DiskSuite documentation provides this, adding DiskSuite to
the mix hasn't been at all painful.

Most of the installations where I have worked use VxVm for all file systems
except the OS; those are usually Solstice Disk Suite or UFS (the logic being
that the OS can be rebuilt in a relatively short time, and the VxVm volumes
re-imported.)  I agree that LSM does have a much more seamless way of
dealing with the systems/OS disks.

This message is more of a commentary than an answer to your query. One has
to do one's own cost/risk/benefit analysis. A detailed answer to your
questions would reveal we use SVM, VxVM, UFS, and VxFS in many situations
where the other could well be used. We have tended to examine the reasons
for choosing and made the decisions for classes of servers, not a blanket
decision for all servers. Obviously, the smaller the support staff, the
better the argument to standardise on one or the other.

First, do not leave root disks encapsulated. It's a hassle. Instead follow
the Sun Blueprint for best VxVM practices, and, after mirroring,
reinitialise the root disk so that it is easily manageable as an ordinary
VxVM disk. This doesn't make upgrading any easier, but it does make
replacement easier when that unfortunate need arises.

Second, I have used VxVM and SVM (SDS, ODS, whatever) for years and been
pretty happy with both. However, I note that with Live Upgrade from Solaris
8 to 9 one still cannot leave the new 9 slices in SVM: they must be plain
slices until one is done. However, one can access non-system slices from the
Live Upgraded system. This is an advantage over VxVM because the SVM is
upgraded with Solaris.

Third, I have found it to be quicker and easier to replace a failed disk
quickly with VxVM than with SVM.

We use both Disk Suite and Volume Manager, more VM than DS. Disk Suite is a
nice little product, but is limited in its application. Volume Manager is
infinitely extensible, so you can add disk array after disk array to your
running system and subdivide it to the Nth degree.

Whichever product we're using for that particular server, we use it across the
board. We do not mix Volume Manager and Disk Suite on a single system.

For our production systems we use Volume Manager, mostly for the minimerge
capabilities when a mirror gets out of sync. We had some troubling problems
with mirror mismatches with Disk Suite, which we fine except they required a
full disk remirror - not something I want to do on a production box in the
middle of the day.

We also have Alpha systems running OpenVMS. On those we use VMS Volume
Shadowing, which is just like Disk Suite, but that's because Volume Manager
isn't available for VMS, and Volume Shadowing is relatively cheap.

they both have appropriate places in an enterprise. ODS/SDS is a perfectly
fine choice for simple things such as mirroring and/or striping but lacks
some nice bells and whistles like soft partitions and shrink online. ok,
well, the newest SDS does support  soft partitions but its really just a
hack....  basically I use VxVM exclusively if I already need it on a machine,
and I
use ODS/SDS if I do not need VxVM.

UFS+Logging v VxFs
Opinions vary here but where UFS is used ensure logging is turned on for all
file systems that can support it.

Always VxFS for oracle file systems because performance is so much better, and
we evaluate
the needs for VxFS on systems that may have high IO needs.  Basically if disk
performance is
an issue it gets VxFS.  UFS + logging hasn't proven itself to be a speedy
system as of yet.

VxFS is by far, a better file system in terms of proven reliability and
performance.   Plus it looks to work with large  500GB+ sizes much better than
UFS has shown itself in the past.  If you are going to spend the bucks to
first purchase VxVM on a large system  ( tier 3 and sometimes even tier 2 ),
you probably have the need for VxFS on it as well for a least
one application.  So once you have a license to run VxFS on a box you might as
well stick with it over UFS+logging just to keep things similar, not to
mention performance.

Veritas file system has really been slower than UFS since Solaris 8 came out
unless you get QuickIO, then it makes up the difference and then some (but it
costs money of course).  Now that Solaris 9 UFS supports snapshots as well I
can see no reason to use Veritas for anything except very specific application
servers (like high transaction Oracle servers).  Even then you may be better
off with straight Solaris for the simplicity and integration.

Fourth, I have had at least two occasions where I had to turn off UFS
logging in order to mount a formerly logged UFS. It simply quit working. I
found this odd because the UFS logging code is the same as what was in SDS
at the time and may be the same as what's in SVM now. Yet, it happened. I
have never had this problem with VxFS.

UFS + logging.  Some suggestions are below.  VxFS is too expensive, and
   if you spread stuff over several drives and get a media problem, it's
   tough to find out what drive is actually failing.

for most things UFS+logging is just fine but for environments with heavy
loads VxFS can really extend the performance of the hardware. e.g. places
like busy: databases, mail, news servers. basically anywhere with small
individual or random i/o will see an improvement.

Sun's new file system and volume manager (formerly developed by LSC) perform
very well against VxFS for high end database needs. the down side is that
the product is still fairly young, management is rough and
administration/tuning can be tedious.

Snapshotting capabilities of Verita
Most didn't comment about this at all.  The message from those that did was
Solaris 8 & above now also has "fssnap" provided native which will do
I was actually aware of this because we use it internally - I was interested
to see how many others use it.

Fifth, one can now take snapshots with UFS, but I haven't tried this
feature, yet. This is one feature where VxFS used to be a clear winner
because only VxFS had it, but no more.

HP-UX  user, do you have any intentions to migrate to VxVm
Not many responded here.

We did use VxVM on HP, but the support folks ( hp support folks ), through
such a hissy fit about it that finally discontinued its use and went back to
HP LVM.  Recover procedures although never tested seemed a little complex on
the HP side with VxVM.  Please note our HP environment and VxVM on HP is very
sunmanagers mailing list
Received on Sun Aug 25 21:55:24 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:55 EST