Why Was: US Military Dead during Iraq War 1837

resources in the particular context were the resources to do the implementation .... aka instead of standard unix port to the real machine interface ... they implemented a VRM abstraction ... which cost resources to build. they then did the unix port to the VRM abstraction ... which appeared to turn out to take significantly more resources than doing a real machine port (contrary to original claims).

the other resource context was the machine resources (and instruction pathlengths) to execute the journal filesystem function. the original implementation relied on the "database memory" function available 801 ... so that (128 byte) blocks of memory could be identified as changed-non-changed for the purpose of logging. this avoided having to put calls to the log function for every bit of metadata changes as they occured. supposedly the "database memory" was to minimize resources need ed to modify existing applications (for logging) as well as the resources (in terms of instruction pathlengths) to execute the logging function. the palo alto work seemed to demonstrate that 1) modifying the unix filesystem code to insert explicit logging function calls wasn't a major effort (which they had to do to port to processors w-o the 801 database memory function) and 2) the explicit calls actually resulted in shorter pathlenght when the function was executing.

with respect to filesystem logging ... the logs have tended to have max size on the order of 4-8 mbytes. keep all changed metadata records in memory until after the related changes have been written to the log, then allow metadata records to migrate to their disk positions (which can be scattered all over the disk surface requiring a large number of independent disk writes). when a set of changes have consistently migrated to disk ... mark those log entries as available. if log fills before that happens, stop things until log entries become available for re-use.

restart-recovery then tends to have a max redo of 4-8mbytes worth of changes applied to the related metadata records. recovery reads the full log ... determines which entries may correspond to metadata that might not have made it to disk (still resident in memory at the time the system failed-shutdown), read those metadata records from disk and apply the logged changes.

the log methodology basically allows the metadata records to be written asyncronously, possibly in non-consistent sequence (say disk arm optimization order rather than metadata consistency order) ... while preserving the appearance of consistent ordering (in case of system shutdown-failure in the middle of incompletely writting some set of metadata records to disk).

the number of active records in the log impacts the restart-recovery time ... but too severely minimizing the number of active records can increase the slow-down points when metadata syncronization to disk has to occur (can possibly get into a situation where there is some trade-off between recovery-restart time against general thruput). An objective is to not noticeably slowdown general thruput while making restart-recovery time still nearly instantaneous.