Hi everybody. My task today is to move my file system that's 98% full to a new partition slice.
I think I'm pretty sure how to do it, but I just wanted to make sure, plus it's been a while since I last did one. The Let's say I have 2 disks c0t0d0 & c0t1d0 ...the file Iwant to move is in c0t0d0s5 & I have a space in c0t1d0s6.
1) When I do format, do I modify c0t1d0.
2) After creating a new slice, I do newfs on the new slice ???? correct?
3) mount the new slice on /tempoary mount point
4) cd to old file
5) tar cf-* |(cd /newmount point; tar xvBpf-)
6) cd .. , unmount /old file , unmount new
7) mount /dev/dsk/c0t1d0s6 /old file name
8) edit /etc/vfstab to refelct new disk & mount point.
The tar part of it is what I'm mostly concern about....Is this right.
You've got that right. Just a couple of things:
step 5: in the tar extraction, do you really need the B switch? I don't think so.
step 8: in the /etc/vfstab you just have to change the /dev/dsk part of the entry that already exists for the current mount point (because you are not going to change the name of the filesystem after you do the copy).
I can't remember which OS versions but it seems from time to time when you check sunsolve ufsdump and ufsrestores have a lot of bug issues. I believe tar previously also has some issues like copying of softlinks but generally much less. I prefer using tar to ufsdump/ufsrestore due to some bad experience.
I recall years ago we did a filesystem migration for an telecom customer, we were quite inexperienced at that time but even then it was a very simple migration job. The migration called for moving his webserver folder from one filesystem to another we used ufsdump | ufsrestore command.
For a 2 GB filesystem It took nearly from midnite when they shutdown the apps till past 9am in the morning, we overshot the downtime window by over 3hrs. And after that the webapplication somehow could not work and require a further 3 more hours of troubleshooting to finally realise what was happening to get it working again. meantime the customer's website was down, There was hell of explaining to the customer as we stood there at the aftermath in the meeting room while their senior managers each took turns grilling us until they were satisfied on how such a simple migration took so long and went horribly wrong.
That folder contained apart from the applicaitons, there was also over 300,000 cookies each no larger than 2k, the ufsdump was very fast it was the ufsrestore that took hours because for each of the 300k files that we restored using ufsrestore it will first create a file inode for each cookie file before doing any restore so it took nearly 4-5 hours just to create the inodes for all 300,000 files before any physical restore could begin. And after it was restored some of the permissions and file ownerships changed.
I think if we used tar it would have been over pretty quickly, I will never forget that experience.
we not really certain here if both c0t0d0 and c0t1d0 are single disk or lun's and part of hardware raid volume or not. If they are lun it will not work.
DD normally we do it for single disk to disk. But you could also be correct in using DD for the remi's migration.
In the case of my migration for the telecom customer, his folder was sitting on a old clariion disk storage system which runs hardware raid, so dd could not be used.
anyway be very careful abt using things like dd, one mistake in placing the wrong disk in the "if" you can say bye bye to your data.
