Subject: CAP to netatalk migration tools
From: Jim Prall (jimp@gandalfgraphics.com)
Date: Wed Apr 26 2000 - 11:56:34 EDT
We have a really large filesystem on Solaris 2.6 served by CAP 6 (pl.198)
We've been aware of netatalk for quite some time, and have in fact
run it on some smaller systems. Recently we've become really concerned
that CAP is not getting any further development. We installed the latest
netatalk +asun on a Solaris 2.6 system we're building up, and we really
liked the performance.
So now we're in the position of needing a plan for migrating our huge
filesystem from CAP to netatalk. This is a busy production system, with
about 200 Gb in use out of 260 Gb available. There is just no way this
is going to get duplicated by dragging files with a Mac. Our intention
is to use unix scripts to walk through all the directories, creating the
required .AppleDouble subdirectory, then populating it with the
correct netatalk-format files derived from info in the existing CAP
.finderinfo and .resource files. We've got a rough idea of what's
involved in writing a tool to do this, but we'd love to discover that
someone else has this written already - however rough. We don't
need a fancy polished tool and we can expand on any pieces that might
be floating around. Can anyone point us toward such a tool, or the
particular details we'll need to treat to write one? We're aware of
the netatalk utility "megatron" but this appears to be targeted at
AppleDouble<->AppleSingle<->BinHex/MacBinary, which all involve
copying the data fork. We really want to avoid touching the data forks,
as (a) many of these are really large and (b) we need to keep file dates
intact. If we change file mod dates, our QuarkXPress jobs on Macintosh
will decide that every art file placed in every publication has been "modified"
and will thus make us sit and wait, and wait, while Quark re-imports all
the picture previews. Ouch.
We've noted with pleasure that netatalk appears to follow the same rule
as in CAP for encoding unix-illegal characters in mac filenames, viz. expanding
them to colon followed by two hex digits. Is anyone aware of any deviation
between netatalk and CAP on, e.g. which exact set of characters are so encoded?
(We'll burrow into the source if nobody has this nailed down already.)
We can do the migration while the filesystem is quiet over a weekend. I
suspect
there would be space enough to leave the CAP pieces behind until we can confirm
that the netatalk conversion is a success - typically the PICT preview at
72 dpi
is the bulk of the resource fork data, and these files tend to have 300 dpi or
higher in the data fork, so resources should be no more than 6% of the disk
usage.
Finally, we had the impression from earlier experiments that it is not safe to
try to run two different Appletalk stacks off the same Solaris box, such as
having both CAP and netatalk running at once. Can anyone confirm if this
is truly verboten, or if there is a way to do it safely? If it could be done,
we would be able to publish a different sub-directory of the big RAID
filesystem
as a netatalk volume, and gradually migrate new work into there as we
gradually migrate off the CAP sub-directory. (We would not try to serve
the same directory with both services, just different locations.)
------
-- Jim Prall jimp AT gandalfgraphics.com
-- Gandalf Graphics Limited
-- 260 Bartley Drive, Toronto, ON Canada M4A 1G5
-- 416-750-2324
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:30:32 EST