MLS & Maprights running 43 hrs & still going. 4.5mil files

Question

Hello,
We need to perform a SAN migration. The customer has a new SAN and we need to migrate the data from the old SAN to the new one. We have an oes2 sp3, 3 node cluster (Virtualized in VMware ESX 4.1). We are using Raw devices and will setup the new LUNs (SAN LUNs) as standalone RDM volumes and make them available to the nodes (not as cluster resources). Once the data & rights (all NSS attributes) are copied over we'll remove the old RDMs and rename/convert the new ones to cluster resources with the same name. This we've done before and works fine. The only problem we have is to "migrate" the File rights. We are currently testing the MLS/MAPRIGHTS solution because the metamig for trustees will only work if the absoulte path is the same and in the beginning it won't be and the restore for a 600GB NSS Volume with 4.5 mil files has already taken 44 hours and is still not finished. Of course this is not acceptable..... 44 hours... WOW! Now I've got 2 questions, are we doing something wrong with the MLS/MIGRIGHTS process? Is there a way to speed it up? The process is local and not over the LAN. The next question is what are your expierences relating to the migration of trustees? What do you use? I'm thinking of testing metamig but that would mean that the original volume would be gone before I could check to see if the trustees were successfully migrated. That of course would or could have a massive effect on my fallback process (return to the original environment if it doesn't work). BTW, we will be using Robocopy to copy the files because migfiles and the other tools are to slow.
Any ideas, help or advice would be greatly appreciated.
Thanks,
Mike

Answer 1

Originally Posted by pvaiq6167
Hello,
We need to perform a SAN migration. The customer has a new SAN and we need to migrate the data from the old SAN to the new one. We have an oes2 sp3, 3 node cluster (Virtualized in VMware ESX 4.1). We are using Raw devices and will setup the new LUNs (SAN LUNs) as standalone RDM volumes and make them available to the nodes (not as cluster resources). Once the data & rights (all NSS attributes) are copied over we'll remove the old RDMs and rename/convert the new ones to cluster resources with the same name. This we've done before and works fine. The only problem we have is to "migrate" the File rights. We are currently testing the MLS/MAPRIGHTS solution because the metamig for trustees will only work if the absoulte path is the same and in the beginning it won't be and the restore for a 600GB NSS Volume with 4.5 mil files has already taken 44 hours and is still not finished. Of course this is not acceptable..... 44 hours... WOW! Now I've got 2 questions, are we doing something wrong with the MLS/MIGRIGHTS process? Is there a way to speed it up? The process is local and not over the LAN. The next question is what are your expierences relating to the migration of trustees? What do you use? I'm thinking of testing metamig but that would mean that the original volume would be gone before I could check to see if the trustees were successfully migrated. That of course would or could have a massive effect on my fallback process (return to the original environment if it doesn't work). BTW, we will be using Robocopy to copy the files because migfiles and the other tools are to slow.
Any ideas, help or advice would be greatly appreciated.
You should really use migfiles to migrate your files. It will correctly migrate your file ownership and rights and you won't need any extra tools to fix your rights. If migfiles is too slow, you might have to look into trying to tune it to make it work better. Sometimes playing with the tsa cache paramters may help a lot.
Another possibility to copy your files is to make sure source and destination volumes are mounted on the same server, extended attributes for NSS are enabled and simply use the Liunux cp command to copy files while specifying that extended attributes should be copied as well. This should also preserve your rights.
For more details, see:
Novell Doc: OES 2 SP3: NSS File System Administration Guide for Linux - Extended Attributes (XAttr) Commands