A few places you could consider some testing to find the problem...
Network
- What physical (network) hardware connects the unRAID server and the Mac?
- How long are any cables?
- Are your network cables old/damaged/kinked at all?
- Are you using a wireless network?
- What's the ping time between the unRAID server and the mac?
- Can you run a long term ping between (ideally with large packet sizes) and see how the response time varies and whether there's any packets lost?
It sounds like it might be a case of high latency or packet loss in the file system access causing issues. If so, then an unreliable network might be a simple thing to fix... but we'll need a bit more info from you about your setup to know if this is the issue.
High ping times (more than a couple of milliseconds) will really slow down access to lots of files (which iTunes will be doing when syncing for example). Packet loss will be even worse, as it might mean a stall for well over a second while attempting to access a file.
SMB Software
- Are you able to test a similar setup using a Windows or Mac machine instead of the unRAID server (perhaps with reduced total library size)?
- Are you able to compile your own version of samba on your Mac (ideally the same version that your unRAID server uses) and mount using that instead of the built-in samba client? (this one I have no idea how to do, but I'm fairly sure would be possible for an experienced UNIX sysadmin/hacker).
By swapping out the unRAID samba server or the built-in OS X SMB client entirely, you may find that it performs equally badly or "just works"... There's every chance that the unRAID server and Mac OS X 10.6.x just don't talk SMB very well together, in which case testing it with a different SMB client/server combination may show improved performance.
It's hard to assign fault if that turns out to be the case, because it could be either the client or server end that are technically not doing the right thing, but it's at least something to test... you might be able to permanently change the server or client SMB software on one machine to solve the problem...
iTunes Software
- Can you test this out on an old version of iTunes? (would require rebuilding the library for that version of course)
If you have access to a machine with an older version of iTunes, you could see if it performs any better... perhaps its just that iTunes can't handle the network-induced lag (which may be at its maximum performance based on your network & SMB server-client setup).
Hopefully you have access to some other computer(s) and/or network hardware to do some of these tests, which should shed light on the underlying cause. Even if its a bug at the high level (with iTunes or unRAID or OS X), it may be something you can mitigate by providing a better (faster? more reliable?) network connection between the two computers. In any case, that should give you somewhere to start, and some more information for us to help...
I was finally able to fix the problem:
- boot into recovery
- unmount all volumes (otherwise gpt will complain that the resource is busy)
- use gpt to remove the partition (it had the HFS instead of the CoreStorage type)
- also delete the partition from the MBR with fdisk (otherwise gpt will not allow you to add the partition).
- finally use gpt to add the partition with the same values but as core storage (type 53746F72-6167-11AA-AA11-00306543ECAC)
Afterwards diskutil cs list showed the volumes again - disk utility repair did the rest. No data lost :)
Best Answer
Apple documents the open source components for each release at the web page:
Internally, they clearly do work before it's publicly documented as we have 10.9.2 out today but only 10.9 is listed publicly with the versions.