Veritas volume manager 5.0 MP3 to 5.1 - vxtunefs

[posie80]

Hi all,

I would like to have some opinion from the experts here on the following :

I am deporting some vxvm 5.0 MP3 volumes from another server and importing it to another server with vxvm version 5.1.

I have no probs importing the volumes of course, but I'm a bit concerned about having these different volumes  version being used on the server having 5.1, specially from performance perspective. The following is the version output of the volume I have just imported :

# /opt/VRTS/bin/fstyp -v /dev/vx/dsk/testdg/testvol1 | grep -i version
magic a501fcf5  version 6  ctime Tue Jun 21 16:03:05 2005

So, I upgraded it to version 7 so now its :

# /opt/VRTS/bin/fstyp -v /dev/vx/dsk/testdg/testvol1 | grep -i version
magic a501fcf5  version 7  ctime Tue Jun 21 16:03:05 2005

So that is ok. However I ran a vxtunefs on a volume I created using the vxvm 5.1 and saw the following :

# vxtunefs /dev/vx/dsk/testdg5.1/testvol5.1

Filesystem i/o parameters for /vx_testvol5.1
read_pref_io = 65536
read_nstream = 1
read_unit_io = 65536
write_pref_io = 65536
write_nstream = 1
write_unit_io = 65536
pref_strength = 10
buf_breakup_size = 1048576
discovered_direct_iosz = 262144
max_direct_iosz = 1048576
default_indir_size = 8192
qio_cache_enable = 0
odm_cache_enable = 0
write_throttle = 0
max_diskq = 1048576
initial_extent_size = 1
max_seqio_extent_size = 2048
max_buf_data_size = 8192
hsm_write_prealloc = 0
read_ahead = 1
inode_aging_size = 0
inode_aging_count = 0
fcl_maxalloc = 130146304
fcl_keeptime = 0
fcl_winterval = 3600
fcl_ointerval = 600
oltp_load = 0

I ran the same command on the volume I just upgraded to version 7 :

# vxtunefs /dev/vx/dsk/testdg/testvol

Filesystem i/o parameters for /vx_testvol
read_pref_io = 65536
read_nstream = 1
read_unit_io = 65536
write_pref_io = 65536
write_nstream = 1
write_unit_io = 65536
pref_strength = 10
buf_breakup_size = 1048576
discovered_direct_iosz = 262144
max_direct_iosz = 1048576
default_indir_size = 8192
qio_cache_enable = 0
odm_cache_enable = 0
write_throttle = 0
max_diskq = 1048576
initial_extent_size = 8
max_seqio_extent_size = 2048
max_buf_data_size = 8192
hsm_write_prealloc = 0
read_ahead = 1
inode_aging_size = 0
inode_aging_count = 0
fcl_maxalloc = 325376000
fcl_keeptime = 0
fcl_winterval = 3600
fcl_ointerval = 600
oltp_load = 0

My question is : I see some differences between the values set with the volume created with 5.1, and the volume created originally from 5.0 (and upgraded successfully to version 7). Namely the fcl_maxalloc and initial_extent_size. I dont really know what these parameters do and if I need to set the values on the newly upgraded volume to be the same. WIll these differences impact performance or can I leave them alone? Perhaps I'm being paranoid here but performance is really key on this server so I would like to cover all the bases if I can.

So appreciate your thoughts and thanks in advance for them!

- Posie

[Gaurav_S · Accepted solution]

This might help you:

fcl_maxalloc

Specifies the maximum amount of space that can be allocated to the VxFS File Change Log. The FCL file is a sparse file that grows as changes occur in the file system. When the space allocated to the FCL file reaches the fcl_maxalloc value, the oldest FCL records are purged from the FCL and the extents nearest to the beginning of the FCL file are freed. This process is referred to as "punching a hole." Holes are punched in the FCL file in 8K chunks. If the file system runs out of space before fcl_maxalloc is reached, the FCL is deactivated.

Either or both of the fcl_maxalloc or fcl_keeptime parameters must be set before the File Change Log can be activated. fcl_maxalloc operates only on Version 6 or higher disk layout file systems.

initial_extent_size

Changes the default size of the initial extent.

VxFS determines, based on the first write to a new file, the size of the first extent to allocate to the file. Typically the first extent is the smallest power of 2 that is larger than the size of the first write. If that power of 2 is less than 8K, the first extent allocated is 8K. After the initial extent, the file system increases the size of subsequent extents (see max_seqio_extent_size) with each allocation.

Because most applications write to files using a buffer size of 8K or less, the increasing extents start doubling from a small initial extent. initial_extent_size changes the default initial extent size to a larger value, so the doubling policy starts from a much larger initial size, and the file system won't allocate a set of small extents at the start of file.

Use this parameter only on file systems that have a very large average file size. On such file systems, there are fewer extents per file and less fragmentation.

initial_extent_size is measured in file system blocks.

All other tuneables are defined here:

http://sfdoccentral.symantec.com/sf/4.1/solaris/manpages/vxfs/vxtunefs_1m.html

Gaurav

[posie80]

Thanks Gaurav! I understand it now :)

Just wondering if these 2 parameters have any impact on performance at all (from your experience?)

- Posie

[Gaurav_S]

Well, to be honest, I have worked with so many environments & I never came across to tune up above mentioned parameters... Defaults just worked beautifully for me...

What application you are using for these volumes ? any DBs ?

Gaurav