0byte files after crash
dillon at apollo.backplane.com
Sat Mar 21 10:05:35 PDT 2009
The main issue seems to be simply that file data is cached in the
buffer cache and filesystems in general try not to flush it out,
but certain other operations such as inode creation and file
extension go direct to the media or, if not direct, modify the
media's meta-data in the buffer cache. A write() which appends
to a file does an inherent file-extension operation in the inode.
So there is a disconnect between data not yet flushed from the buffer
cache and meta-data (the inode) which is likely to be flushed sooner.
Softupdates makes things worse, but the essential problem for UFS
is the disconnect between the data getting flushed and the inode
HAMMER works slightly differently. HAMMER does not modify meta-data
at all until its background flush, and the flush mechanic sequences
data onto the media prior to sequencing the inode onto the media.
However, because data is buffered in the buffer cache multiple writes
which touch only the buffer cache become dis-ordered from their
associated inode updates. It just isn't possible to give each discrete
write() its own transaction id when it is overwriting previously
written data that is still sitting dirty in the buffer cache.
Thus, with HAMMER, the transaction id used to created the inode may
wind up being different from the transaction id used to write the data.
Both transaction ids wind up getting flushed in the same HAMMER
flush sequence, however. So if you use undo -i to look at the file's
transaction id history you will sometimes see some zero-fill relative
to particular transaction ids, but you should (hopefully) never see
it relative to crash recovery or relative to explicit snapshots.
I would like to fix this, I haven't figured out a good way to do it
due to the data overwrite/rewrite interactions with the buffer cache.
More information about the Kernel