Moving mountpoint and filesystem from one LUN to another

[Glenn Mitchell_2]

'no action required yet... but soon...
I am running out of space in LUN0 and need to move one of the lvols to LUN1.

I want to make sure that all filesystem attributes and ownership remains the same (doesn't change to root).

The only thing I can think of doing is make a new mount point on LUN1 with a new name, copy over all of the file structure from LUN0, delete the old LUN0 filestructure.

Saving the filestructure to tape and recovering to the new mount point is very slow. Is there an easy way of doing this? The man files on the mv command indicates that I will loose the attributes and ownerships will change to root - not good.

Please advise.

Thank you

[A. Clay Stephenson]

You are doing this the hard way. By far the easiest method is to add the new LUN to your existing volume group (or diskgroup if this is VxVM).

1) Create a new LUN (it should be no larger than your largest existing LUN in the existing VG.
2) ioscan -fn
insf
# this will let the host "see" the new LUN
3) pvcreate /dev/rdsk/cXtYdZ # create a new physical volume (PV)
4) use vgextend to add the new PV to your existing VG
5) Now use lvextend to "grow" your old LVOL(s)
6) Now use fsadm -Fvxfs to extend the filesystems (or extendfs if you don't have OnlineJFS)
7) Declare victory

You can actually do all of this with the system up and running and if you have OnlineJFS, you can extend the filesystem(s)
"on the fly" while the application is up and running. If this sounds complicated then SAM -> Disks & Filesystems will actually do all the steps for you (although it's a wimpy approach for a real sysadmin).

[Ivan Ferreira]

You can use fbackup/frecover, like this:

fbackup -i /lun0 -f - | (cd /lun1; frecover -Xrf -)

[Mel Burslan]

you can look into using vxdump/vxrestore as follows


SOURCEFS=/my/source/fs
DESTINFS=/my/destination/fs

cd ${SOURCEFS}
xvdump 0f - ${SOURCEFS} | (cd ${DESTINFS} ; vxrestore xf -)

it is quite fast. As a matter of fastest method we could find to do a host copy when we were migrating from one SAN device to the other couple of years ago.

hope this helps

[James R. Ferguson]

Hi Glenn:

This is easily accomodate with 'cpio' or 'fbackup':

# cd srcdir && find . -depth -print | cpio -pudlmv dstdir

# cd srcdir && fbackup -i . -f - | ( cd dstdir && frecover -Xsrf - )

..where 'srcdir' is your old mountpoint and 'dstdir' is your new mountpoint (logical volume). When done, edit '/etc/fstab' to change the device file associated with the 'srcdir' mountpoint and eliminate the 'dstdir' mountpoint. In that way you will have exchanged the logical volumes while retaining your original mountpoint directory name.

The advantage to 'fbackup' is that is handles largefiles and sparse files.

Regards!

...JRF...

[Mel Burslan]

sorry about the typo in my previous message it is not xvdump it is vxdump... fingers were fasterthan the brains. It must be the time to go home :)

[Glenn Mitchell_2]

I got a bit confused with that one Clay. I'm not sure what the new LUN will do, and I don't have Online JFS. Let me clarify my problem...

My system is N4000 with HP-UX 11.11

LUN0 has numerous lvols dedicated to numerous databases. 2 of those lvols on LUN0 are 98% full (8GB on one and 10GB on the other). On LUN0 I only have a few MB free, while on LUN1 I have about 15GB free.

I need to move the 8GB lvol from LUN0 to LUN1 and lvextend it out another 4GB. After the move, I can remove the old lvol to free up 8GB of space on LUN0. I can then lvextend the remaining 10GB full lvol in LUN0 and extend it out to 15 GB (and still have room for other growth).

Whichever way I go I'll need a full backup to tape before attempting a fix. A tape recovery to a new lvol will be slow. I was hoping to find a solution at processor speed.

Thank you.

[Glenn Mitchell_2]

Will fbackup or cpio retain the file attributes and ownership "as is"?

[James R. Ferguson]

Hi (again) Glenn:

You asked, "Will fbackup or cpio retain the file attributes and ownership 'as is'?"

Yes. For more information, simply see the respective manpages.

Regards!

...JRF...

[Glenn Mitchell_2]

Thank you all for your inputs to answer my questions. I find myself leaning more toward the fbackup or cpio solutions. I need to read a few more man pages before making the decision.

Thank you again.

[A. Clay Stephenson]

That's the beauty of LVM; a volume group can be comprised of multiple physical volumes (PV's -- LUN's in your case -- and if these are disk array LUN's then that PV can actually be comprised of multiple physical disks --- all invisible to LVM). So my approach is to carve out an additional LUN only as big as you need to accomodate the extra space. You then add that LUN to your existing volume group and you can then increase the size of your existing LVOL's. It's perfectly ok for LVOL's to span PV's. Once the LVOL's are expanded, you can extend the filesystems. Because nothing is actually copied, no permissions or ownerships are changed. Because you do not have OnlineJFS (get a baseball bat and whack yourself because no HP-UX box should be without it), you will need to shutdown the database(s) and unmount the filesystems before doing the extendfs's.

While I would suggest that you take a backup before doing this, I can tell you that I have done this very operation hundreds of times "on the fly" without a single hiccup. You will be done in a fraction of the time your copy operation will take.

By the way, if you are going to do a copy then an fbackup/frecover pipeline is the way to go because tar and cpio have a 2GiB maximum file size limit (ok, 8GiB with tar, if patched).