vxfsconvert: usage or not-to-use! - Veritas Volume Manager

This is a discussion on vxfsconvert: usage or not-to-use! - Veritas Volume Manager ; Hi All -- Recently, we have been performing host based data migrations to migrate from the older to newer storage frames. At the server level, the source filesystems are of "ufs" type. The goal is to make destination filesystems as ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: vxfsconvert: usage or not-to-use!

  1. vxfsconvert: usage or not-to-use!


    Hi All --

    Recently, we have been performing host based data migrations to
    migrate from the older to newer storage frames.

    At the server level, the source filesystems are of "ufs" type. The goal
    is to make
    destination filesystems as "vxfs" type. We in engineering have proposed
    to create the destination filesystem as "vxfs" from grounds-up. Then copy
    the data from the source to the destination filesystems. So that data gets
    reside in the clean vxfs container.

    The SAs want to take a different approach. They want to mirror the source
    to the destination volumes first leaving the underlying filesystems as "ufs"
    type during the data migration. Then they want to use "vxfsconvert" utility
    to convert from "ufs" to vxfs" type.

    Is this a recommended / correct approach? Can someone give me points to support
    my argument with the SAs to use the approach which we in engineering are
    proposing? Has anyone performed the performance benchmarks to see if there's
    any performance implications to the approach by converting "ufs" to vxfs"
    by using the "vxfsconvert" utility?

    Any help will be appreciated. Please assist as early as you can.

    thanks!
    --Asim;



  2. Re: vxfsconvert: usage or not-to-use!

    Well, depends on what you want as the outcome.

    Doing the new filesystem and then copy the data across, will make better
    use of the filesystem and will make it faster (metadata will be created
    and extend allocation will be a lot better)

    On the other hand, doing the mirror, converting that to vxfs will leave
    less room for error (not saying that you will mess it up, but there is
    always potential to do so) and will not impact on access to the
    "original" files on UFS.

    The big issue with UFS to vxfs conversions is the layout of the
    resulting filesystem.

    UFS uses blocks (called cylinder blocks). Each cu\ylinder block contains
    a superblock and then some metadata (used by the filesystem) and then
    some user data.

    VXFS contains the metadata in files (that can only be accessed by the
    filesystem) as well as some special blocks for holding special structures.

    When converting a UFS to VXFS, the conversion goes cylinder block by
    cylinder block. For each new cylinder block, new files are created
    (files contains stuff like inodes, free inodes, extents, ....)

    In general (for small files) this is not too bad (as the metadata needs
    to be close to the data), but for larger files, this means that more
    than 1 metadata "file" needs to be created and the searching for
    metadata can consume time, which will in turn slow down the filesystem.
    The same goes for extent allocation (a VXFS extent is a series of
    consecutive blocks, which speeds up read-aheads specifically on larger
    files)



    So, as long as you can put procedures in place to double check data on
    the copy process as well as make sure that all the data is copied
    (without problems and impacting he original files), the copy would
    result in the best performin VXFS


    Asim Zuberi wrote:
    > Hi All --
    >
    > Recently, we have been performing host based data migrations to
    > migrate from the older to newer storage frames.
    >
    > At the server level, the source filesystems are of "ufs" type. The goal
    > is to make
    > destination filesystems as "vxfs" type. We in engineering have proposed
    > to create the destination filesystem as "vxfs" from grounds-up. Then copy
    > the data from the source to the destination filesystems. So that data gets
    > reside in the clean vxfs container.
    >
    > The SAs want to take a different approach. They want to mirror the source
    > to the destination volumes first leaving the underlying filesystems as "ufs"
    > type during the data migration. Then they want to use "vxfsconvert" utility
    > to convert from "ufs" to vxfs" type.
    >
    > Is this a recommended / correct approach? Can someone give me points to support
    > my argument with the SAs to use the approach which we in engineering are
    > proposing? Has anyone performed the performance benchmarks to see if there's
    > any performance implications to the approach by converting "ufs" to vxfs"
    > by using the "vxfsconvert" utility?
    >
    > Any help will be appreciated. Please assist as early as you can.
    >
    > thanks!
    > --Asim;
    >
    >


+ Reply to Thread