Re: Issues with metaSAN

yes, all machines should be data masters.

we noticed this crash behavior at all times of the day, but one thing that seemed to trigger it was when the server would check for updates.

our XServe raid apparently has a known issue with the en0/1 port that causes kernel panics and logs have shown the en0 port specifically causes our crashes. that port is only used for internet traffic for the master, not metadata (en1) and no AFP/SMB sharing (we use a bonded line for that). all of that likely doesn't apply to your situation being windows.

also, i would generate support logs from both the master and a client, and Tiger want's to know the exact time the crash happens in the email you send. If your logs are too big to attach, they can set you up with an FTP site to upload.

worth mentioning, we now defrag our volumes every 2 months and we reformat them twice a year. we use one volume as a way point for data while we reformat the other, vice versa. we had a major crash/freeze once that was caused by fragmentation. when you move your data around avoid multiple copy processes, try to cue up all your data to copy at once.

best of luck,

bk