How to test whether application handles slow/flaky filesystems properly?

Question

I want to ensure that my application doesn't have any UI freezes when working on files on slow filesystem (e.g. networked, CD/DVD or spun-down HDD).

I'm using Cocoa filesystem operations directly. I'm afraid it would be too much effort to mock or abstract all of it just for testing, and besides there could be non-obvious ways in which my program touches filesystem.

I've tried using network drives for testing, but OS caching makes tests non-repeatable and... too fast :)

Is there something like deliberately slow MacFuse filesystem? Some other method that would let me find all UI hiccups and race conditions caused by unexpected delays?

Answer 1

Maybe buy a slow thumb drive? I've found some at Best Buy that were glacial. Plug them in through several USB hubs and maybe a keyboard, as well, so they'll be on a very pokey connection.

-W

Answer 2

Writing a MacFUSE filesystem with their Cocoa framework is dead easy. In fact I think there's even an example system included that just mirrors the local filesystem. Why not quickly adapt that code so that it calls sleep() for a moment during every operation?

Answer 3

Depending on where you're worried about having problems, my first thought would be to just include an extra layer of function calls between the app and the file i/o, and in that layer build in some sleep() calls. That is, whatever language you're using, replace the "read" call with "readDelegate", and let readDelegate sleep for some specified amount of time, then do the real read and return the value. When you're ready to go to production, you wouldn't even have to pull out the extra layer, just remove the sleep.

Answer 4

The easiest answer is MacFUSE as noted elsewhere; that's pretty easy to simulate. You could also try mounting a share over NFS and then use bit throttling it using the built-in ipfw, like:

ipfw pipe 1 config 1KByte/s ipfw add 1 pipe 1 src-port 2049

or if you're using WebDAV

ipfw add 1 pipe 1 src-port 80

This will then drip-feed the requests through at whatever pipe level you've defined. You should be able to get rid of it again afterwards with:

ipfw delete 1

Answer 5

How about a floppy drive? There must be external ones that you can simply connect via usb or so...