CRC data failed?

[Matthew Dillon]

:>It sounds like the filesystem image got corrupted, your best bet is
:>to wipe it completely (w/ newfs_hammer).
:
:Only a handfull of files seem to have a problem, so for now I will leave as 
:it. I guess I could try deleting those files.
:
:>  It is possible to recover the data to another filesystem (not in-place) 
:>if you need the data.
:
:Will do. I will setup another VM. The original data was downloaded over DSL 
:and took almost a week to download.
:
:>Checking the entire filesystem's CRCs can be done by issuing a 
:>mirror-read redirected to /dev/null and seeing if any errors pop
:>up.  This will wind up reading the entire disk and could take some
:>time depending on the size of the filesystem.
:
:Where can I read about how to do that?

    'man hammer' gives you a lot of information.  The integrity checks are
    integrated into the mirror-read code but we haven't wrapped it with
    something more user friendly.

:Also, is the crash possibly due to the fact it is in a VM? This is my first 
:production test of DragonFly, so I am trying to understand what happened. If 
:this was a sever with original data, I would be pretty worried about the 
:data.
:

    The problem is basically that the VM lies to the kernel when the kernel
    tries to flush the disk cache, telling the kernel that the disk cache
    has been flushed when the data has not actually been synced to the
    physical media.  This means that when a crash of the host occurs
    (verses the guest), the state of the data on the physical media winds
    up being different than what the HAMMER recovery code expects.

    On a real system the disk flush command actually works properly.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>