The idea is that any modified block instead of getting dirtied is gets
locked and put on a list of "held" blocks. When a transaction is
finished, the corresponding log records are written and once the log
records are all known to have reached the disk, then the lock is
removed from the modified buffer heads and they are actually dirtied.
Yup, that's a hack alright. :-)
However, doesn't this have the problem that while the buffer is blocked,
other processes that need to access that want to read from that buffer
will block until the buffer head is unlocked? Or if you're not letting
the original filesystem transaction complete until the log records are
flushed to disk, that would seem to have some really nasty performance
problems.
The only solution which I've thought of which avoids this problem is
having a pseudo device, which orders writes by moving copying data
between the pseudo-device (on which the filesystem is actually mouned),
and the actual disk device, with the writes happening under the control
of the pseudo-device. This chews up extra memory for the extra copies
of the block buffers for the pseudo-device though. No hack is perfect.
:-/
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu