What is a Journalled File System?

Reading back through one of my entries on 1 December, I realise that I've talked about journalled file systems, but didn't explain what one is.

A journalled file system is one which records (on disk) the changes it's about to make before doing so. If the power fails, or an error occurs, while it's making the changes, it can then either reverse the changes made, or read forwards through the log to complete the changes. This allows the system to ensure that its changes are consistent.

These features allow the file system to be both fast, caching writes until a lot of changes can be made at once, and also reliable. Classic UNIX file systems cache writes and rely on a checking tool, fsck (File System ChecKer), to fix the mistakes that happen. Windows 98 FAT and FAT32 work in the same way, relying on scandisk to sort out the corrupted disk. VMS and other reliable systems use serialised access to file system structures: only one process can modify disk structures at a time, but this is s-l-o-w.

One thing that isn't often explained about JFSs is that only the disk structure is journalled. User data is not necessarily preserved. The file will be the right length, but might not have the right contents. If you need transactional behaviour (operations are either completely performed or completely rolled back) you need to implement this yourself. Windows NT does this for its registry, which is why you're less likely to get a trashed registry on this system (and indeed, this is safer than multiple individual configuration files).

According to the big honking Longhorn architecture chart, Longhorn will gain built-in support for transactional access to files, and general transaction support.

Users of Pocket PCs might be surprised to learn that the file system implemented in the device's RAM is also transactional, as is access to the device's registry and property databases. AFAIK, Palm is not. However, the Pocket PC implementation has a 'feature' - changes to a property database appear not to be committed until you close the last handle to it. The CEDB OLE DB provider (which most PPC developers know as 'Pocket Access') doesn't close handles until you've Released the last Connection reference. If the device is suspended with an outstanding Connection open, the device rolls back and loses all your changes.

Unsurprisingly, we don't use ADOCE at work.