Re: 0byte files after crash

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    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
    getting flushed.

    --

    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.

						-Matt