[Veritas-vx] odd behavior of vxresize?

[Gene Huft]

Gurus:
I have a striped volume - it had one nice little subdisk on each 32 GB physical disk. I wanted to expand this volume & it's filesystem to it's maximum. Here is the before picture:

v datavol01 - ENABLED ACTIVE 129208320 SELECT datavol01-01 fsgen
pl datavol01-01 datavol01 ENABLED ACTIVE 129212416 STRIPE 4/2048 RW
sd datadg05-01 datavol01-01 datadg05 0 32303104 0/0 c2t5d1 ENA
sd datadg08-01 datavol01-01 datadg08 0 32303104 1/0 c2t5d7 ENA
sd datadg07-01 datavol01-01 datadg07 0 32303104 2/0 c2t5d6 ENA
sd datadg06-01 datavol01-01 datadg06 0 32303104 3/0 c2t5d0 ENA

So, I wanted to find how much I could grow to:
# vxassist -g datadg maxgrow datavol01 alloc=datadg05,datadg06,datadg07,datadg08
Volume datavol01 can be extended by 154931200 to 284139520 (138740Mb)

Then, I executed vxresize:
# /usr/lib/vxvm/bin/vxresize -g datadg datavol01 284139520 \ alloc=datadg05,datadg06,datadg07,datadg08

When it was all done, I noticed it had created an additional subdisk for each physical disk:
# vxprint -htr -st -g datadg

v datavol01 - ENABLED ACTIVE 284139520 SELECT datavol01-01 fsgen
pl datavol01-01 datavol01 ENABLED ACTIVE 284139520 STRIPE 4/2048 RW
sd datadg05-01 datavol01-01 datadg05 0 32303104 0/0 c2t5d1 ENA
sd datadg05-02 datavol01-01 datadg05 32305152 38731776 0/32303104 c2t5d1 ENA
sd datadg08-01 datavol01-01 datadg08 0 32303104 1/0 c2t5d7 ENA
sd datadg08-02 datavol01-01 datadg08 32305152 38731776 1/32303104 c2t5d7 ENA
sd datadg07-01 datavol01-01 datadg07 0 32303104 2/0 c2t5d6 ENA
sd datadg07-02 datavol01-01 datadg07 32305152 38731776 2/32303104 c2t5d6 ENA
sd datadg06-01 datavol01-01 datadg06 0 32303104 3/0 c2t5d0 ENA
sd datadg06-02 datavol01-01 datadg06 32305152 38731776 3/32303104 c2t5d0 ENA

And the filesystem is still about 7GB smaller than it should be:
df -k | grep datavol01

Filesystem kbytes used avail capacity Mounted on
/dev/vx/dsk/datadg/datavol01 133189842 49358662 77774580 39% /f01

I don't really want the extra sub-disks, and how can I get the additional space back? These disks are completely free of any other sub-disks. I do have 4 additional disks to work with, these are the ones I'd planned to create a mirror of this volume.
I suppose I could do a bunch of vxmakes's & create sub-disks on the unused disks, then do a series of vxsd mv's and joins.....but what about my extra space?

TIA,

--Gene

[Darren Dunham]

I have a striped volume - it had one nice little subdisk on each 32 GB =
physical disk. I wanted to expand this volume & it's filesystem to it's =
v datavol01 - ENABLED ACTIVE 129208320 SELECT =
datavol01-01 fsgen
pl datavol01-01 datavol01 ENABLED ACTIVE 129212416 STRIPE 4/2048 =
RW
sd datadg05-01 datavol01-01 datadg05 0 32303104 0/0 c2t5d1 =
ENA
sd datadg08-01 datavol01-01 datadg08 0 32303104 1/0 c2t5d7 =
ENA
sd datadg07-01 datavol01-01 datadg07 0 32303104 2/0 c2t5d6 =
ENA
sd datadg06-01 datavol01-01 datadg06 0 32303104 3/0 c2t5d0 =
ENA
# vxassist -g datadg maxgrow datavol01 alloc=3Ddatadg05,datadg06,datadg07,d=
atadg08
Volume datavol01 can be extended by 154931200 to 284139520 (138740Mb)
# /usr/lib/vxvm/bin/vxresize -g datadg datavol01 284139520 \ alloc=3Ddatadg=
05,datadg06,datadg07,datadg08
When it was all done, I noticed it had created an additional subdisk for =
# vxprint -htr -st -g datadg =
=20
v datavol01 - ENABLED ACTIVE 284139520 SELECT =
datavol01-01 fsgen
pl datavol01-01 datavol01 ENABLED ACTIVE 284139520 STRIPE 4/2048 =
RW
sd datadg05-01 datavol01-01 datadg05 0 32303104 0/0 c2t5d1 =
ENA
sd datadg05-02 datavol01-01 datadg05 32305152 38731776 0/32303104 c2t5d1 =
ENA

So you're noting that there's a (small) space between 32303104 and
32305152. That 2k blocks or 1Mb per disk that you're missing. Times 4
disks, that's 4 megs.

df -k | grep datavol01
Filesystem kbytes used avail =
capacity Mounted on
/dev/vx/dsk/datadg/datavol01 133189842 49358662 77774580 39% /f01
I don't really want the extra sub-disks, and how can I get the additional =
space back? These disks are completely free of any other sub-disks. I do =
have 4 additional disks to work with, these are the ones I'd planned to =
create a mirror of this volume. =20
I suppose I could do a bunch of vxmakes's & create sub-disks on the unused =
disks, then do a series of vxsd mv's and joins.....but what about my extra =
space?

I'm not sure exactly what I'd do at this point, but your problem is
almost certainly that the end of the original subdisks wasn't aligned on
a cylinder boundary. The default for vxassist is to create subdisks
only on cylinder boundaries. Since that couldn't be done without
leaving a space, it created the new subdisk rather than extending the
old one.

It's a format specification that can be used...

diskalign, nodiskalign
Aligns (default) or does not align subdisks on
cylinder boundaries. When alignment is not dis-
abled, subdisks are created beginning on cylinder
boundaries and are extended to match the end of a
cylinder. [...]

So, I believe that the original subdisks were created with nodiskalign,
and your extension was created with (the default of) diskalign,
otherwise they would have matched up.

If you could recreate the original setup (shrink the filesystem, shrink
the volume, shrink the plex, remove the new subdisks), and redo your
command with nodiskalign, I think you'd get no extra subdisks.

Since you have disks suitable for mirroring, you could use them to
mirror everything (contiguously) and then throw away the original. Then
you could extend and get your 4MB back and remirror.

That doesn't explain your filesystem shortfall. I'm not sure why that's
occured.

[Gene Huft]

Thanks for reply Darren,
I still have issues with the filesystem size being too small (see very bottom), but what I wound up doing to get back to one subdisk per disk was to write a script that did the following overnight:

1. Made 2 contiguous sub-disks, on each of my 4 unused disks, each subdisk being the same size as the sub-disks in the volume. Example:

vxmake -g datadg sd datadg01-01 disk=datadg01 offset=0 len=32303104
vxmake -g datadg sd datadg01-01 disk=datadg01 offset=32303104 len=38731776

2. Then I did a bunch of (very time consuming) sub-disk moves to the "new" disks:

vxsd -o rm mv datadg05-01 datadg01-01
vxsd -o rm mv datadg05-02 datadg01-02

3. Did a bunch of subdisk joins - so I got back to just one subdisk on each:

vxsd -g datadg join datadg01-01 datadg01-02 datadg01-01

4. Recreated one "max size" subdisk on each of the disks that I just moved off of:

vxmake -g datadg sd datadg05-01 disk=datadg05 offset=0 len=71036928

5. Then I moved the subdisk data back into these newly created "max size" subdisks:
(NOTE: you must use the -o force in order to put a smaller sized sd into a larger one)

vxsd -o force mv datadg01-01 datadg05-01

6. When all this mess was done, I then got back the small amount of space (8192k x 4) by growing the volume with:

vxassist -g datadg growto datavol01 284147712 alloc=datadg01,datadg02,datadg03,datadg04

( I got some errors concerning space not available on the disks - but It grew the volume....I think
this is understandable, the plex was larger than the volume at this point because my -o force's!)

7. and then grew the UFS filesystem with:
/usr/lib/fs/ufs/mkfs -F ufs -M /f01 /dev/vx/dsk/datadg/datavol01 284147712


!!BUT!! I still can't figure out the space loss issue, when I do a vxprint -htr -g datadg datavol01, it shows the size of my volume in sectors as 284147712, in my calculation this is about 145GB, which would seem about right if I have 4x36GB disks. But the vxsa GUI shows the disks at 33.6 GB each, and my volume size at 135.5 GB. My UFS filesystem is tuned to 1% minfree, so I have no Idea why this filesystem isn't any larger than 133GB:
df -k
/dev/vx/dsk/datadg/datavol01 133193682 49363800 82497946 38% /f01

The following filesystem has exactly HALF the size as above (2 36GB drives in striped volume), and it lists 70GB:

/dev/vx/dsk/datadg/oravol01 70892144 26603184 43580040 38% /u01

--Clueless in Seattle

Gene

I have a striped volume - it had one nice little subdisk on each 32 GB =
physical disk. I wanted to expand this volume & it's filesystem to it's =
v datavol01 - ENABLED ACTIVE 129208320 SELECT =
datavol01-01 fsgen
pl datavol01-01 datavol01 ENABLED ACTIVE 129212416 STRIPE 4/2048 =
RW
sd datadg05-01 datavol01-01 datadg05 0 32303104 0/0 c2t5d1 =
ENA
sd datadg08-01 datavol01-01 datadg08 0 32303104 1/0 c2t5d7 =
ENA
sd datadg07-01 datavol01-01 datadg07 0 32303104 2/0 c2t5d6 =
ENA
sd datadg06-01 datavol01-01 datadg06 0 32303104 3/0 c2t5d0 =
ENA
# vxassist -g datadg maxgrow datavol01 alloc=3Ddatadg05,datadg06,datadg07,d=
atadg08
Volume datavol01 can be extended by 154931200 to 284139520 (138740Mb)
# /usr/lib/vxvm/bin/vxresize -g datadg datavol01 284139520 \ alloc=3Ddatadg=
05,datadg06,datadg07,datadg08
When it was all done, I noticed it had created an additional subdisk for =
# vxprint -htr -st -g datadg =
=20
v datavol01 - ENABLED ACTIVE 284139520 SELECT =
datavol01-01 fsgen
pl datavol01-01 datavol01 ENABLED ACTIVE 284139520 STRIPE 4/2048 =
RW
sd datadg05-01 datavol01-01 datadg05 0 32303104 0/0 c2t5d1 =
ENA
sd datadg05-02 datavol01-01 datadg05 32305152 38731776 0/32303104 c2t5d1 =
ENA

So you're noting that there's a (small) space between 32303104 and
32305152. That 2k blocks or 1Mb per disk that you're missing. Times 4
disks, that's 4 megs.

df -k | grep datavol01
Filesystem kbytes used avail =
capacity Mounted on
/dev/vx/dsk/datadg/datavol01 133189842 49358662 77774580 39% /f01
I don't really want the extra sub-disks, and how can I get the additional =
space back? These disks are completely free of any other sub-disks. I do =
have 4 additional disks to work with, these are the ones I'd planned to =
create a mirror of this volume. =20
I suppose I could do a bunch of vxmakes's & create sub-disks on the unused =
disks, then do a series of vxsd mv's and joins.....but what about my extra =
space?

I'm not sure exactly what I'd do at this point, but your problem is
almost certainly that the end of the original subdisks wasn't aligned on
a cylinder boundary. The default for vxassist is to create subdisks
only on cylinder boundaries. Since that couldn't be done without
leaving a space, it created the new subdisk rather than extending the
old one.

It's a format specification that can be used...

diskalign, nodiskalign
Aligns (default) or does not align subdisks on
cylinder boundaries. When alignment is not dis-
abled, subdisks are created beginning on cylinder
boundaries and are extended to match the end of a
cylinder. [...]

So, I believe that the original subdisks were created with nodiskalign,
and your extension was created with (the default of) diskalign,
otherwise they would have matched up.

If you could recreate the original setup (shrink the filesystem, shrink
the volume, shrink the plex, remove the new subdisks), and redo your
command with nodiskalign, I think you'd get no extra subdisks.

Since you have disks suitable for mirroring, you could use them to
mirror everything (contiguously) and then throw away the original. Then
you could extend and get your 4MB back and remirror.

That doesn't explain your filesystem shortfall. I'm not sure why that's
occured.

[Gene Huft]

(Oops! had to fix a typo on step 6 below)

Thanks for reply Darren,
I still have issues with the filesystem size being too small (see bottom), but what I wound up doing to get back to one subdisk per disk was to write a script that did the following overnight:

1. Made 2 contiguous sub-disks, on each of my 4 unused disks, each subdisk being the same size as the sub-disks in the volume. Example:

vxmake -g datadg sd datadg01-01 disk=datadg01 offset=0 len=32303104
vxmake -g datadg sd datadg01-01 disk=datadg01 offset=32303104 len=38731776

2. Then I did a bunch of (very time consuming) sub-disk moves to the "new" disks:

vxsd -o rm mv datadg05-01 datadg01-01
vxsd -o rm mv datadg05-02 datadg01-02

3. Did a bunch of subdisk joins - so I got back to just one subdisk on each:

vxsd -g datadg join datadg01-01 datadg01-02 datadg01-01

4. Recreated one "max size" subdisk on each of the disks that I just moved off of:

vxmake -g datadg sd datadg05-01 disk=datadg05 offset=0 len=71036928

5. Then I moved the subdisk data back into these newly created "max size" subdisks:
(NOTE: you must use the -o force in order to put a smaller sized sd into a larger one)

vxsd -o force mv datadg01-01 datadg05-01

6. When all this mess was done, I then got back the small amount of space (8192k x 4) by growing the volume with:

vxassist -g datadg growto datavol01 284147712 alloc=datadg05,datadg06,datadg07,datadg08

( I got some errors concerning space not available on the disks - but It grew the volume....I think
this is understandable, the plex was larger than the volume at this point because my -o force's!)

7. and then grew the UFS filesystem with:
/usr/lib/fs/ufs/mkfs -F ufs -M /f01 /dev/vx/dsk/datadg/datavol01 284147712


!!BUT!! I still can't figure out the space loss issue, when I do a vxprint -htr -g datadg datavol01, it shows the size of my volume in sectors as 284147712, in my calculation this is about 145GB, which would seem about right if I have 4x36GB disks. But the vxsa GUI shows the disks at 33.6 GB each, and my volume size at 135.5 GB. My UFS filesystem is tuned to 1% minfree, so I have no Idea why this filesystem isn't any larger than 133GB:
df -k
/dev/vx/dsk/datadg/datavol01 133193682 49363800 82497946 38% /f01

The following filesystem has exactly HALF the size as above (2 36GB drives in striped volume), and it lists 70GB:

/dev/vx/dsk/datadg/oravol01 70892144 26603184 43580040 38% /u01

--Clueless in Seattle

Gene

I have a striped volume - it had one nice little subdisk on each 32 GB =
physical disk. I wanted to expand this volume & it's filesystem to it's =
v datavol01 - ENABLED ACTIVE 129208320 SELECT =
datavol01-01 fsgen
pl datavol01-01 datavol01 ENABLED ACTIVE 129212416 STRIPE 4/2048 =
RW
sd datadg05-01 datavol01-01 datadg05 0 32303104 0/0 c2t5d1 =
ENA
sd datadg08-01 datavol01-01 datadg08 0 32303104 1/0 c2t5d7 =
ENA
sd datadg07-01 datavol01-01 datadg07 0 32303104 2/0 c2t5d6 =
ENA
sd datadg06-01 datavol01-01 datadg06 0 32303104 3/0 c2t5d0 =
ENA
# vxassist -g datadg maxgrow datavol01 alloc=3Ddatadg05,datadg06,datadg07,d=
atadg08
Volume datavol01 can be extended by 154931200 to 284139520 (138740Mb)
# /usr/lib/vxvm/bin/vxresize -g datadg datavol01 284139520 \ alloc=3Ddatadg=
05,datadg06,datadg07,datadg08
When it was all done, I noticed it had created an additional subdisk for =
# vxprint -htr -st -g datadg =
=20
v datavol01 - ENABLED ACTIVE 284139520 SELECT =
datavol01-01 fsgen
pl datavol01-01 datavol01 ENABLED ACTIVE 284139520 STRIPE 4/2048 =
RW
sd datadg05-01 datavol01-01 datadg05 0 32303104 0/0 c2t5d1 =
ENA
sd datadg05-02 datavol01-01 datadg05 32305152 38731776 0/32303104 c2t5d1 =
ENA

So you're noting that there's a (small) space between 32303104 and
32305152. That 2k blocks or 1Mb per disk that you're missing. Times 4
disks, that's 4 megs.

df -k | grep datavol01
Filesystem kbytes used avail =
capacity Mounted on
/dev/vx/dsk/datadg/datavol01 133189842 49358662 77774580 39% /f01
I don't really want the extra sub-disks, and how can I get the additional =
space back? These disks are completely free of any other sub-disks. I do =
have 4 additional disks to work with, these are the ones I'd planned to =
create a mirror of this volume. =20
I suppose I could do a bunch of vxmakes's & create sub-disks on the unused =
disks, then do a series of vxsd mv's and joins.....but what about my extra =
space?

I'm not sure exactly what I'd do at this point, but your problem is
almost certainly that the end of the original subdisks wasn't aligned on
a cylinder boundary. The default for vxassist is to create subdisks
only on cylinder boundaries. Since that couldn't be done without
leaving a space, it created the new subdisk rather than extending the
old one.

It's a format specification that can be used...

diskalign, nodiskalign
Aligns (default) or does not align subdisks on
cylinder boundaries. When alignment is not dis-
abled, subdisks are created beginning on cylinder
boundaries and are extended to match the end of a
cylinder. [...]

So, I believe that the original subdisks were created with nodiskalign,
and your extension was created with (the default of) diskalign,
otherwise they would have matched up.

If you could recreate the original setup (shrink the filesystem, shrink
the volume, shrink the plex, remove the new subdisks), and redo your
command with nodiskalign, I think you'd get no extra subdisks.

Since you have disks suitable for mirroring, you could use them to
mirror everything (contiguously) and then throw away the original. Then
you could extend and get your 4MB back and remirror.

That doesn't explain your filesystem shortfall. I'm not sure why that's
occured.

[T***@open.ac.uk]

Gene,

I think you are confused by the way vendors specify their disk sizes. When
they say their disk size is 36Gb, they really mean it is 36*1000*1000*1000
bytes, rather than 36*1024*1024*1024 bytes. Veritas uses proper gigabytes,
so your vendor's 36Gb disk appears to shrink to about 33.5Gb under Volume
Manager. Does this explain your lost disk space?

Tim

______________________________________________________________
Tim Robinson
The Open University

-----Original Message-----
Sent: Thursday, March 07, 2002 12:19 AM
To: veritas-vx
Subject: [Veritas-vx] Re: odd behavior of vxresize?
(Oops! had to fix a typo on step 6 below)
Thanks for reply Darren,
I still have issues with the filesystem size being too small (see bottom),
but what I wound up doing to get back to one subdisk per disk was to write
1. Made 2 contiguous sub-disks, on each of my 4 unused disks, each subdisk
vxmake -g datadg sd datadg01-01 disk=datadg01 offset=0 len=32303104
vxmake -g datadg sd datadg01-01 disk=datadg01 offset=32303104 len=38731776
2. Then I did a bunch of (very time consuming) sub-disk moves to the
vxsd -o rm mv datadg05-01 datadg01-01
vxsd -o rm mv datadg05-02 datadg01-02
3. Did a bunch of subdisk joins - so I got back to just one subdisk on
vxsd -g datadg join datadg01-01 datadg01-02 datadg01-01
4. Recreated one "max size" subdisk on each of the disks that I just moved
vxmake -g datadg sd datadg05-01 disk=datadg05 offset=0 len=71036928
5. Then I moved the subdisk data back into these newly created "max size"
(NOTE: you must use the -o force in order to put a smaller sized sd into a
larger one)
vxsd -o force mv datadg01-01 datadg05-01
6. When all this mess was done, I then got back the small amount of space
vxassist -g datadg growto datavol01 284147712
alloc=datadg05,datadg06,datadg07,datadg08
( I got some errors concerning space not available on the disks - but It
grew the volume....I think
this is understandable, the plex was larger than the volume at this point
because my -o force's!)
/usr/lib/fs/ufs/mkfs -F ufs -M /f01 /dev/vx/dsk/datadg/datavol01
284147712
!!BUT!! I still can't figure out the space loss issue, when I do a
vxprint -htr -g datadg datavol01, it shows the size of my volume in
sectors as 284147712, in my calculation this is about 145GB, which would
seem about right if I have 4x36GB disks. But the vxsa GUI shows the disks
at 33.6 GB each, and my volume size at 135.5 GB. My UFS filesystem is
tuned to 1% minfree, so I have no Idea why this filesystem isn't any
df -k
/dev/vx/dsk/datadg/datavol01 133193682 49363800 82497946 38% /f01
The following filesystem has exactly HALF the size as above (2 36GB drives
/dev/vx/dsk/datadg/oravol01 70892144 26603184 43580040 38% /u01
--Clueless in Seattle
Gene
11:26AM >>>

I have a striped volume - it had one nice little subdisk on each 32 GB =
physical disk. I wanted to expand this volume & it's filesystem to it's

=

v datavol01 - ENABLED ACTIVE 129208320 SELECT =
datavol01-01 fsgen
pl datavol01-01 datavol01 ENABLED ACTIVE 129212416 STRIPE 4/2048

=

RW
sd datadg05-01 datavol01-01 datadg05 0 32303104 0/0 c2t5d1

=

ENA
sd datadg08-01 datavol01-01 datadg08 0 32303104 1/0 c2t5d7

=

ENA
sd datadg07-01 datavol01-01 datadg07 0 32303104 2/0 c2t5d6

=

ENA
sd datadg06-01 datavol01-01 datadg06 0 32303104 3/0 c2t5d0

=

ENA
# vxassist -g datadg maxgrow datavol01

alloc=3Ddatadg05,datadg06,datadg07,d=

atadg08
Volume datavol01 can be extended by 154931200 to 284139520 (138740Mb)
# /usr/lib/vxvm/bin/vxresize -g datadg datavol01 284139520 \

alloc=3Ddatadg=

05,datadg06,datadg07,datadg08
When it was all done, I noticed it had created an additional subdisk for

=

# vxprint -htr -st -g datadg

=

=20
v datavol01 - ENABLED ACTIVE 284139520 SELECT =
datavol01-01 fsgen
pl datavol01-01 datavol01 ENABLED ACTIVE 284139520 STRIPE 4/2048

=

RW
sd datadg05-01 datavol01-01 datadg05 0 32303104 0/0 c2t5d1

=

ENA
sd datadg05-02 datavol01-01 datadg05 32305152 38731776 0/32303104

c2t5d1 =

ENA

So you're noting that there's a (small) space between 32303104 and
32305152. That 2k blocks or 1Mb per disk that you're missing. Times 4
disks, that's 4 megs.

df -k | grep datavol01
Filesystem kbytes used avail

=

capacity Mounted on
/dev/vx/dsk/datadg/datavol01 133189842 49358662 77774580 39% /f01
I don't really want the extra sub-disks, and how can I get the

additional =

space back? These disks are completely free of any other sub-disks. I

do =

have 4 additional disks to work with, these are the ones I'd planned to

=

create a mirror of this volume. =20
I suppose I could do a bunch of vxmakes's & create sub-disks on the

unused =

disks, then do a series of vxsd mv's and joins.....but what about my

extra =

space?

I'm not sure exactly what I'd do at this point, but your problem is
almost certainly that the end of the original subdisks wasn't aligned on
a cylinder boundary. The default for vxassist is to create subdisks
only on cylinder boundaries. Since that couldn't be done without
leaving a space, it created the new subdisk rather than extending the
old one.
It's a format specification that can be used...
diskalign, nodiskalign
Aligns (default) or does not align subdisks on
cylinder boundaries. When alignment is not dis-
abled, subdisks are created beginning on cylinder
boundaries and are extended to match the end of a
cylinder. [...]
So, I believe that the original subdisks were created with nodiskalign,
and your extension was created with (the default of) diskalign,
otherwise they would have matched up.
If you could recreate the original setup (shrink the filesystem, shrink
the volume, shrink the plex, remove the new subdisks), and redo your
command with nodiskalign, I think you'd get no extra subdisks.
Since you have disks suitable for mirroring, you could use them to
mirror everything (contiguously) and then throw away the original. Then
you could extend and get your 4MB back and remirror.
That doesn't explain your filesystem shortfall. I'm not sure why that's
occured.
--
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco, CA bay area
< How are you gentlemen!! Take off every '.SIG'!! >
_______________________________________________
<http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx>