With this commit, Mike Larkin (mlarkin@) has added support for hibernating to encrypted softraid(4) devices. This is what he had to say when asked about it:

After RLE support (which went in in Slovenia), the next thing on the list to tackle was softraid crypto. Theo provided the initial idea on how to get the block transforms and crypto bits working over lunch one day in Slovenia and after about three or four days of on-and-off hacking this week, we had it working.

For those new to hibernate, one of the key challenges is to keep the machine as idle as possible while snapshotting/writing out the memory image. In order to do this, one of the things you need is an I/O write routine that is completely side-effect free (or at least whose side-effects are constrained to known locations). Obviously, if the I/O routine is making changes in memory as the image is being written out, that's not good. This means no memory allocations, no spl*/splx, no printfs, etc, can occur during image write. We have had ahci and pciide/wd side-effect free routines in the tree for some time now.

One difference with softraid though is that now we need two side-effect free I/O functions - one for softraid itself and one for whatever disk controller happens to be serving the volume containing the softraid paritions (eg, ahci/wd). Since those inner I/O routines expect their own block biasing, there needed to be some adjustment to the block numbers that get passed down through the stack. And with softraid crypto, if you get the block number wrong, you mess up the encryption which leads to an unrestorable image. Much was learned in how to do this the easy way by looking at the softraid crypto boot loader code, and indeed this is how we modeled the hibernate softraid crypto code in the end.

The performance of the implementation is probably not as good as it could be as presently we are processing a disk block at a time. With more scratch pages available to the routine, we could batch as many as 8 blocks at once to be sent down to the underlying I/O routine. We'll probably revisit that some day as part of an overall improvement in the hibernate write path performance (which with the recent addition of RLE is really not bad anymore)