Today has been enormously frustrating, fighting a laundry list of intertwingled, although sort of unrelated, problems. The goal, this morning, was to import some stuff into svn, and then get a checkout of it on a Windows server. Sounds simple, right?

Tortoise SVN would not install, due to a missing/outdated file on the Windows machine. So I ran Windows Update. It hung, consuming 100% of the CPU, for the entire morning. I’ve seen these updates take a long time, so I just left it. When I came back after lunch, and it was still running, I killed it, and tried to take another approach.

Plan B – Mount the drive via samba over to the Linux machine on which svn is hosted, and perform the svn checkout “locally” to that mounted drive. This should work just fine, right? Well, I kept getting Input/Output errors, dropped connections. Had to delete files, run svn cleanup, and then try to update again. This went on until about 5:30, when I finally opened a ssh tunnel home, so that I could come home and connect back out.

I got home, but when I connected back out, everything was painfully sluggish, and, eventually, all the connections locked up, and I could not open a new shell. I had almost decided to go back to the office, when I got a shell, and discovered that the load was at 24. Oy.

It seems, after much poking about, that I’m tickling a known, but unresolved, bug in Samba, discussed here, as well as possibly here, among other places. So, for once, it’s actually not Window’s fault at all. Well, not directly, at least. If they didn’t have such a broken network file system in the first place, this would likely not be an issue at all.

The symptoms also seemed to include, at least once, smbiod consuming all the CPU, as well as a huge amount of RAM. But that didn’t happen again, so that could have been a fluke.