I’ve been hard at work for the past couple of weeks, and I’m proud to announce that an updated fsfsverify script is available. Functionally, the only difference is the addition of svndiff1 support. Underneath, the great majority of the code has changed to make it easier to support different types of svndiff streams. It should also be easier to hack, if you find yourself needing to add a feature. Enjoy!
Archive for February, 2007
Things are going well on the fsfsverify front. I’ve run the new code through a number of tests, and it’s performing just as well as the old one. If this keeps up, I’ll have it out the door this week.
I’ve been hard at work on a new version of fsfsverify that handles the new svndiff1 format. I also took it as an opportunity to rewrite large portions of it, because it’s clearly leading a life of it’s own. So far it has seen 330 downloads by 278 unique ip addresses since June of last year. I’m sure many of those were people just curious about the script. However, I know people are indeed using it, since I get emails declaring success, and occasionally ones that ended in failure (hey, I can’t fix data loss).
At any rate, I hope to finish up most the remaining items over the next week or so. As always, real life takes precedence, so that may end up being more like a month.
I appreciate those folks who have emailing me to let me know how things went. I try to keep tabs on just how wide-spread the issue is, and the emails help greatly. The only thing I ask is that along with your emails, please provide some details about your setup. Which OS, which version of the OS and Subversion. How are you accessing it (svn://, http://, etc)? What quality was the link when the corruption occured? Local lan? Over a modem? Is it reliable? Is it latent? Have you experienced any hard disk errors? Memory errors?
It’s important to provide that information because it can help us narrow the field and make sure we fix the issue. To date, no dev has been able to reproduce the problem. Until we can reproduce the problem, we can’t really understand what’s causing it.
One nifty feature on most modern macs is that you can disable processors on the fly. Up front, that doesn’t sound like much of a benefit, but in reality it is. As a developer, I can examine the compute time using different processor configurations, and see how well the software scales.
One problem that I ran into is determining the number of available processors. From sysctl’s man page, it shows an entry for ‘hw.ncpu’. However, that’s the number of processors installed on the machine, not the number of active processors. ’sysctl -a’ turned up the setting I was looking for: ‘hw.availcpu’. Actually, there was another one called ‘hw.activecpu’ that seemed to operate in the same way–it changed when hw.availcpu changed. However sys/sysctl.h recommended using hw.availcpu as the mechanism to determine the number of threads to create for SMP aware applications.
So, for those of you developing SMP aware apps on the Mac, hw.availcpu is the value you need to use.