This post is more than 5 years old
5 Posts
0
1878
April 15th, 2010 08:00
Migrating data from AFP to Celerra CIFS
Hi everyone,
We are looking to move data hosted on 3x Apple Xserve's (Leopard 10.5) to a new Celerra (running code 5.6.47-11). I assume other EMC customers have moved from a similar environment and am interested in knowing the method you used to copy data from Apple->Celerra, challenges encountered, or any suggestions you may have in general.
At the moment we are testing data copy via the following:
- Mount AFP (Xserve) user volume and CIFS (Celerra) user volume on a Snow Leopard workstation
- In Terminal, we use cp -Rvp /Volumes/ /Volumes/ to copy data from user's AFP volume to CIFS volume
... this seems to work fine, preserving modification dates, resource forks, etc. The one thing we've noticed so far is there are some file/foldername characters that AFP is fine with however not so with CIFS. We are using a tool (Namecleaner X) to cleanup file/foldernames so they are CIFS compliant.
Any feedback would be appreciated.
Many thanks,
Darren
IanSchorr
117 Posts
0
April 16th, 2010 02:00
Just to throw in another $0.03 (adjusted for inflation),
Generally most successful migrations I've seen from AFP servers to CIFS servers (specifically Celerra) have gone pretty much exactly like you say. In the olden days "ditto" would have been the preferred utility (since it was Resource-Fork aware) but the modern Apple "cp" generally does everything that needs to be done.
Besides the fact that AFP/HFS+ supports characters not supported in CIFS/Windows (and you've found a good solution for that), Resource Fork handling is probably the biggest potential gotcha. Like Rainer said, fresh 10.6 clients, 10.5 and below or upgraded 10.6 clients, and systems using Thursby's Dave or ADmitMac CIFS clients all handle Resource Forks in different ways, and if you have a mixture of these clients in your environment things might get a little bit messy. But otherwise, you shouldn't have any other general problems.
If you have 10.6 clients, make sure you're running the latest versions of OS X (10.6.3) and Celerra code (at least 5.6.47 or later). Both updates contain some fairly critical bugfixes for CIFS/OS X compatibility.
Be careful if your source AFP volume and destination CIFS volume have the same name, and you plan to keep both volumes mounted for a while. OS X also still has a peculiar bug that can really confuse applications (particularly MS Office) if two volumes are mounted with the same name at the same time. With certain types of filesystem calls, OS X will accidentally send I/O to the FIRST volume with a particular name, even if the application intended the I/O to go to the SECOND volume with that name. This has tripped up at least a few Mac migratees - the workaround in that case is just to unmount the AFP volume, or make sure they're mounted/exported using different names.
umichklewis_ac7b91
300 Posts
1
April 15th, 2010 08:00
Hi Darren -
The only advice I can offer is to make sure that you have UTF-8 enabled on the Celerra (Snow Leopard should have UTF-8 enabled by default, unless changed during installation). We export CIFS shares via SMB to many Mac OS X clients running 10.4 and later. So far, I have no reports of filename issues, though.
You might want to consider a third-party app to help with your file migration - ExtremeZ-IP (http://www.grouplogic.com/products/extremeZ-IP/).
It has a 21-day trial license, which might be enough to get you through your migration. In an email thread from a few weeks ago, another department recommended this tool for some of the admins in their environment, with a mix of MacOS X 10.6.3, Vista and Win2008 R2.
Hope this helps!
Karl
Rainer_EMC
6 Operator
•
8.6K Posts
1
April 15th, 2010 09:00
yes - make sure that you do have Unicode enabled on the data mover and that you are using the correct code pages
Rainer_EMC
6 Operator
•
8.6K Posts
1
April 15th, 2010 10:00
also make sure you understand the difference between AppleSingle and AppleDouble - esp. if you also have 10.5 clients that have a different default there than 10.6
see https://community.emc.com/thread/101664?tstart=0
Rainer
djanisse-beresk
5 Posts
0
April 16th, 2010 12:00
Many thanks for the great suggestions everyone, I appreciate it.
We have a mixture of OS X 10.4 (120 users), 10.5 (80 users) and 10.6 (20 users). Seeing as a fresh install of 10.6 uses named streams by default, should we disable this feature in Mac OS X for the time being as noted in Apple KB article HT4017? For example, a 10.6 user would create a Word document, save it to the Celerra. Would there be any problems with a 10.4 user opening that same document, writing changes, etc?
Thanks!
Darren
IanSchorr
117 Posts
0
April 18th, 2010 17:00
The impact of "losing" resource forks varies from application to application. There ARE a small number of applications that store critical data in these forks, but for the most part apps just tend to store non-critical file metadata. Though I haven't found a reference that says definitively, from experience I believe that MS Office apps tend to store authoring info, but not much else. That's actually fairly typical. I can say that when there are resource fork problems, MS Office apps are typically NOT what our customers seem to notice problems in.
Some apps store only metadata, but the metadata can be deceptively important. For example, Photoshop tends to store file preview info in PSD files. Losing this info (or not being able to "see" this info) can have a large impact on some workflows. If you're browsing through a large directory of content looking for some photo, for example, you might want to see previews/thumbnails of the content. If the thumbnails aren't available, that alone would impact your users. But if the data's missing out of the resource fork, Photoshop will generate a preview on-the-fly...by reading the whole file. If the files are large (10+MB is not uncommon), that can take a long time. So not only does it potentially take a while to see your thumbnails, but access to a directory might be slow (while it reads ALL files), plus the client is generating a TON of unnecessary I/O, leading to performance problems.
Mac OS also stores some things itself for all/most files, including potentially application association (something that is going away again in 10.6) and some OS tagging/indexing info. But for the most part it is NOT info that'd really cause your users any/much headache.