Mbuttive io 829

... note that the journal file system for aixv3 (started in the late 80s) took a database logging approach to filesystem metadata.

in the cms filesystem case ... the records containing changed filesystem metadata was written to new disk record location ... and then the MFD was rewritten as a kind of commit to indicate the new metadata state ... as opposed to the old metadata state. the EDF filesystem in the mid-70s, updated the original cms filesystem (from the mid-60s) to have two MFD records ... to take care of the case where there was a power failure and a write error of the MFD record happening concurrently.

the aixv3 filesystem took a standard unix filesystem ... where metadata information had very lazy write operations and most fsync still had numerous kinds of failure modes ... and captured all metadata changes as they occured and wrote them to log records ... with periodic specific commit operations. restart after an outage was very fast (compared to other unix filesystems of the period) because it could just replay the log records to bring the filesystem metadata into a consistent state.

there was still an issue with incomplete writes on the disks of the period. the disk tended to have 512byte records and the disks were defined to either perform a whole write or not do the write at all (even in the face of power failure). The problem was that a lot of the filesystems were 4kbyte page oriented ... and consistent "record" writes met a full 4k ... involving eight 512byte records ... on device that only guaranteed the consistancy of a single 512byte record write (but there could be inconsistency where some of the eight 512byte records of a 4k "page" were written and some were not).