The support for the orphaned Drobo FS is sad, sad, sad. With every update of Mac OS X it’s just gotten slower and slower to the point of me having to retire it from its duties as a primary NAS for our workstations to a creaky, old archive server. In just under 3 years, my FS has gone from 50MB/s Writes & 70MB/s Reads to 20MB/s Writes & 40MB/s Reads. Dismal USB2 speeds.
That said, has anyone noticed a constant stream of Console messages like this?
kernel[0]: AFP_VFS afpfs_vnop_getxattr: bad address
I’m not sure what it means, but of course popping up in the Console never seems like a good sign. My biggest worry is that it’s reflecting data corruption, which for an archive/backup server would be very bad indeed.
Wow - I’m personally amazed you ever got throughput like the original speeds. My couple years on an FS was always the latter speeds (under 40MBps).
I wouldn’t worry about xattr stuff too much. Sounds like there’s some very minor corruption, but netatlkd maintains xattr information on a folder-by-folder basis, so at most you should see issues with a single directory. While it’s possible for there to be useful information in an extended attribute (like a comment or label), just as often it’s something you don’t need like quarantine flags, time machine exclusions, etc.
AFP_VFS afpfs_vnop_getxattr: bad dataLength offset 2 replySize 2, tenths per second!
Is there a possibility that my ethernet link to the Drobo isn’t clean?
That I have no idea, I’m afraid. I’d think if a bad connection were causing issues, then you’d see much more serious effects than that. Still sounds to me like netatalkd crapped out on something - but I’m afraid I can’t offer more advice.
Thank you for answering. I investigated further by moving the Drobo to my closer switch and it didn’t change anything. My console is no unreadable, flooded by this messages.
Do you think I should contact the Drobo support about it?
They might be able to suggest something akin to blowing away netatalkd’s databases. I know the feeling of errors overwhelming Console.app; I was using an old fan control program that spewed SMC errors at mine non-stop. Makes it a real pain in the rear to get real troubleshooting done.
I too was suffering with the error. Nobody seemed to have the answer. Good thing that I am stubborn. I have found an easy solution that is so easy it is sick. Mount you unit with cifs. Just use cifs://yournameserver instead of afp://yourusername. Thank you TUAW.
Well, yeah - the problem is with AFP and by doing that you’re bypassing AFP. However, you’re also going to lose the metadata stored there (which may or may not matter).
Be careful with such a solution - different network protocols store things differently on disk, and files written with one might not be readable on another. For instance, NFS allows me to create filenames with characters that aren’t valid for AFP, so I can see the files when connected with AFP, but I can’t actually read them (solution is to go back to NFS).
Not to say this won’t work out for you, but you’re avoiding rather than solving the problem, and it may have consequences later.
There is no solution, Apple is driving the ship and shows no interest of maintaning AFP as their default network for file sharing. Apple is moving away from AFP and moving to SMB2 protocol. This is now the default in Mavericks.
Regardless, the AFP issues here are not being caused by Apple, but by the netatalkd daemon that provides AFP on the Drobo FS/5N and every other Linux system. Eventually such systems will move to SMB2, but I expect that to take a long time (years) and I don’t know how much work Samba has put into SMB2. In short - things might get worse before they get better, but this one can’t be pinned on Apple.
