Solaris moving a File System to Another Partition on the Fly using SVM

Joseph Gan, August, 2004

Let’s say you need to move the data of a file system from one partition to another on a disk unit such as a Sun RSM Array, a Sun StorEdge T3 array, or a RAID device from StorageTek. This generally involves dismounting the file system, backing it up to tapes, and restoring it to a new partition. You may also copy the file system from one place to another while it is unmounted. This process could take a significant amount of time for a large file system, and it will impact the use of the system.

To move a file system to a different partition on the fly, you can use Solaris Volume Manager software. If you don’t need to expand the file system, you don’t even have to mount it as a metadevice. In the end, you only need to dismount the file system, and mount it onto the new partition. All the processes can be executed in the background while the file system is still in use.

You can swap to the new partition at any time. This can reduce system downtime in many cases. Let’s use the /home file system as an example:

# df -k /home
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t2d1s3 50700783 39746386 10530839 80% /home

First, on top of this physical mount point of the /home file system, create a metadevice named d101. Remember, the /home file system is still mounted.

# metainit -f d101 1 1 c0t2d1s3

Next, you need to initialize a one-way mirror metadevice, d100, with the submirror d101 you have created.

# metainit d100 -m d101
# metastat d100
d100: Mirror
    Submirror 0: d101
      State: Okay
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Size: 102961152 blocks
d101: Submirror of d100
    State: Okay
    Size: 102961152 blocks
    Stripe 0:
        Device              Start Block  Dbase State        Hot Spare
	c0t2d1s3                   0     No    Okay

Now it’s time to create a single-stripe metadevice (in this example, d102 on c0t2d1s7), where the target file system would be. The size of the new partition should be the same as d101.

# metainit d102 1 1 c0t2d1s7
d102: Concat/Stripe is setup

# metastat d102
d102: Concat/Stripe
    Size: 102975488 blocks
    Stripe 0:
        Device              Start Block  Dbase
        c0t2d1s7                   0     No

After that, you add the metadevice d102 as the second submirror to d100. Here the resynchronization will automatically take place in the background.

# metattach d100 d102

After the resynchronization has been completed successfully, here’s an example of the two-way mirrors you would get:

# metastat d100
d100: Mirror
    Submirror 0: d101
      State: Okay
    Submirror 1: d102
      State: Okay
    Pass: 1
    Read option: roundrobin (default)
    Write option: parallel (default)
    Size: 102961152 blocks
d101: Submirror of d100
    State: Okay
    Size: 102961152 blocks
    Stripe 0:
        Device              Start Block  Dbase State        Hot Spare
	c0t2d1s3                   0     No    Okay

d102: Submirror of d100
    State: Okay
    Size: 102961152 blocks
    Stripe 0:
        Device              Start Block  Dbase State        Hot Spare
	c0t2d1s7                   0     No    Okay

Now, you have a new partition for the /home file system, ready to swap at any time while it’s still online.

With your user, you can schedule when to dismount the home file system. You can then mount the system to the new partition on c0t2d1s7, shown as follows:

# df -k /home
Filesystem kbytes used avail capacity Mounted on
/dev/dsk/c0t2d1s7 50700783 39746386 10530839 80% /home

Finally, you’ll detach and clean up all metadevices from your system:

# metadetach d100 d101
d100: submirror d101 is detached

# metaclear d101
d101: Concat/Stripe is cleared

# metaclear d100
d100: Concat/Stripe is cleared

# metaclear d102
d102: Concat/Stripe is cleared

Now you have performed fewer than 10 steps, and the /home file system has been moved dynamically.

---

Please note: This procedure must be done during a quiet period, or the file system must be locked, in order to avoid possible changes to the file system during the sync. You can use the fuser -u command to check that no one is using the file system. If users are logged on overnight in their logging directory, the system admin could write-lock the file system if it is possible. In that case, users can still read files in the directory. As long as no one creates files during the sync, everything will be fine.

Source:

http://www.sun.com/bigadmin/content/submitted/moving_filesystem.html