On Nov 16, 2007, at 11:09 AM, Flynn, Daniel wrote:
Good Day List,
Xserve G4
OS X 10.4.9
Xserve RAID, 2 LUN's of 6X250GB HDD's striped via Apple RAID 1.
Direct connected via copper SFP-SFP cables.
During periods of high IO (I think) RAID volume unmounts.
<snip>
This happens consistently when an rsync cron job is enabled.
<snip>
On Nov 16, 2007, at 3:28 PM, Marcus Lingl wrote:
I have had this very same exact thing happen to me. Made me bang
my head against the wall. In my case, it was also an rsync cron
job that made the volume unavailable to the OS (for writing,
anyways -- users could still read, but make no changes). Would
bring up an error -50 in the Finder anytime someone tried
writing to the volume.
I switched to using unison instead of rsync and haven't had the
problem since. It's slower, but works like a champ.
On Nov 23, 2007, at 10:05 AM, Dan Shoop wrote:
Have either of you bothered to turn off spotlight when doing high
I/O operations to your volumes???
On Nov 23, 2007, at 4:13 PM, Marcus Lingl wrote:
Yes, I made sure that spotlight was turned off when doing my
troubleshooting. And by "off" I mean that I disabled indexing for
the volume by doing "mdutil -i off <volume_name>". If that is
incorrect, please correct me. I would be more than happy to re-
test my syncing with rsync to see if the I/O errors come back.
Now that I went back to look at my troubleshooting notes, I
remember that the I/O errors only happened if I used the -E switch
with rsync. When I removed the -E switch, no more I/O errors.
Unfortunately, the files I am syncing absolutely require their
resource forks. ACLs are not enabled on either volume being
sync'd. Both volumes are HFS+ (Journaled). I noticed with rsync
(with -E), that it copies the resource fork for every file,
whether the file changed or not (in my case that meant ~150,000
files copied on each sync). Unison also copies the resource fork,
but seemingly not in the I/O pummeling manner that rsync does :)
Maybe it's what you meant, but you'll need to use the full path for
the volume name, eg:
mdutil -i off /Volumes/<volumename>
With rsync, you need typically need to break up the job(s) to keep
it from falling.
And yes, seen that: with -E it copies the resource fork every time.
That was my error. I did mean the full path to the volume.
