"The Linux Gazette...making Linux just a little more fun!"

Hey answer guy!!!

From Nate Brazell on Mon, 31 May 1999

Wow!

I really didn't expect a response. And certainly not one as detailed as this!!!

Thanks Dennis.

I do have questions regarding this part:
>> mount $NEWFS /mnt/tmp (Mounting my new FS)
>> cp -pax $OLDDIR /mnt/tmp (Copying all data to /mnt/tmp)
>> umount /mnt/tmp (unmounting /mnt/tmp? Where does my data go?)

Your data stays both in $OLDDIR and on the filesystem that you had mounted on /mnt/tmp and which you'll be mounting over a new (empty) mount point which has the same name as the directory that contains the original copy of your data).

See the next couple of commands:
>> mv $OLDDIR $OLDDIR.old (Moving directories)
>> mkdir $OLDDIR (recreating directory)
>> chmod $OLD_DIR_PERMS $OLDDIR (Setting perms)
>> mount $NEWFS $OLDDIR (Mounting new FS)

Using these commands you now have two copies of your data. One copy is named .../$OLDDIR.old and the other is a new filesystem mounted on .../$OLDDIR

After you've verified, to your satisfaction, that everything is alright after your change, you can remove the old copy with 'rm -fr $OLDDIR.old'

In general there are two ways to transparently migrate data from one filesystem to another under UNIX.

The method I've describe moves the data onto a new filesystem that's mounted directly under the old location. Another method is to create a new filesystem on an arbitrary mount point (conventionally /u1, /u2, etc). and the original directory is replaced with a symlink to point to a directory under that new fs.

In either case it's possible that some differences will not be entirely transparent. In particular some files might have had hardlinks that crossed the boundary of the directory tree. Those links would now be broken (resulting in two separate files where formerly you had one file with two or more links. This is rarely a problem. However you could test for this case with a bit of scripting and editing.

Mainly you generate a report using 'find'. Use something like:

find $FSROOT -xdev -not -type d -links +1 \
	-printf "%i %p\n" | sort -n

... where $FSROOT is the root of whichever filesystem houses the directory tree that you're trying to migrate.

This prints a list of files sorted by their inodes. Any set of hard links to a given file have their device number and inode pair in common. You can then manually seach the resulting list (usually fairly short). For any even file you don't have to worry at all if all of its links, or none of its links, are under the subdirectory tree that you are moving. Probably there will be none that have this problem. For those that do, simply replace one set of the hard links with symlinks. In other words, all of the hard links that are inside the target directory tree should be converted to symlinks, or vice versa.

It's very unlikely that this will cause any problem. If you ever see a case where a UNIX or Linux program suffers from "transplant shock" I'd like to hear about it.

Where is the old data that needs to go back into the newly created $OLDDIR?

You copied it with the 'cp -pax'

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 43 July 1999

HTML transformation by Heather Stern of Starshine Techinical Services, https://www.starshine.org/

	1	2	3
	4	5	6
	7	8	9