May 9th, 2005

belize

diskchecker.pl

Dear Slashdot comment flood: I didn't write the summary in the Slashdot story. The submitter did. I know the disks themselves don't handle an fsync().

I know fsync() only tells the operating system to flush. This script tests whether fsync works end-to-end. A database in userspace can only fsync... it can't send special IDE or SCSI "flush your buffers" commands to the disks. So that's what I care about and what I want to test: that a database can be Durable.

The problem is manufacturers shipping SCSI disks with a dangerous option (hardware write-caching) enabled by default. It makes sense for consumer ATA stuff, but for SCSI disks that already have reliable TCQ, there's much less point. And any respectable raid card should just disable write-back caching on the disks if the raid card has its own nvram-backed cache, but LSI doesn't anymore (they used to, but stopped).

And I'm glad Linux is finally starting to tell the disks to flush on an fsync. But months ago I was stuck with databases that couldn't survive power outages and needed a way to test whether everything from the filesystem to the block device driver to the disks themselves were doing what the database expected when it did an fsync. That's no component's job alone, so I needed to test everything together.


Remember my disk-checker program I wrote about before? I'd never released it because it was too hard to use, but now it's dead simple, so here it is:

http://code.sixapart.com/svn/tools/trunk/diskchecker.pl Edit: now https://gist.github.com/3172656

Run it and be amazed how much your disks/raid/OS lie. ("lie" = an fsync doesn't work)

It seems everything from PATA consumer disks to high-end server-class SCSI disks lie like crazy. Yes, that includes SATA there in the middle. I'll discuss fixing your storage components in a second.

In a nutshell, run it like this:

Tester machine (machine that won't crash):
$ diskchecker.pl -l

And then just let it chill. (the el is for listen). This program will listen (on port 5400 if no number follows -l) and will write one tiny file per host to /tmp/. It can be run as any user.

Machine being tested (machine you're going to pull the power cable on)
$ diskchecker.pl -s TESTERMACHINE create test_file 500

That creates a 500 MB file named "test_file" and it reports everything it's about to do and does to the TESTERMACHINE (which can be an IP or hostname).

Now, pull the power cable on the machine being tested. Don't turn it off nicely. Don't just control-C the program. Wait a couple seconds and plug your testee machine back in and reboot it. When it's back up, do:

$ diskchecker.pl -s TESTERMACHINE verify test_file

If the server process is still running, the machine you just killed will connect to the server and information about what's supposed to be where. The client will then verify it and produce an error report.

What you should see is:

Total errors: 0.

But you probably won't. You'll probably see an error count and a histogram of errors per seconds-before-crash. Most RAID cards lie (especially LSI ones), some OSes lie (rare), and most disks lie (doesn't matter how expensive or cheap they are). They lie because their competitors do and they figure it's more important to look competitive because the magazines only print speed numbers, not reliability stats. They must figure people who care about their disks working know how to test/fix their disks.

Ways to maybe fix your disk:

hdparm -W 0 /dev/hda -- worked on a crap office PATA disk (and it failed otherwise)
scsirastools -- need this on lots of SCSI disks. you'll probably have to remove your SCSI disks from your RAID card and fix the disks directly, since RAID cards very often won't disable it for you

Anybody have anything else to add?

Enjoy.
belize

command-line bug/todo/issue tracking

Is there a good bug/todo/issue tracking system that does both of:

-- stable, defined API for external clients to use. No, not just doing an HTTP POST to the parameters that the current version happens to use, and then screen-scraping the HTML result.

-- dependencies Bugzilla has these. FogBogz doesn't, I hear. But then FogBugz doesn't have an API either.

That's all I want. Then I can do little command-line apps to add items, add dependencies, list my things, move jobs between people, etc. And edit my entire to-do list in $EDITOR and sync it with "minitask sync" or something.

I find typical issue tracking systems way too heavy. I can't use FogBugz or Bugzilla for most my stuff because I add/remove small items (to my scraps of paper) too quickly. But I don't want to use scraps of paper. And I want to be able to throw items from my scraps of paper to others.

If this mythical system I dream of did have a web interface (and it should, for people who like those sorts of things), it'd just be a consumer of the API, and not hit the database (be it a database, svn, flat files) itself at all. It could be a 100 line perl *.cgi file for all I care, and it'd be plenty fast.

What am I looking for? This project's too boring to write.