BFBI OTT bug or limitation? UPDATE2

[Matthew Dillon]

:Bill Hacker wrote:
:> Top-posting to my own post ...
:
:Again.
:
:Reproduced the original verbose crash. Only the last line is the same as 
:below.
:
:Failed to set up the HP-200LX serial, so will run it again...
:
:Bill
: 
:> :-(
:> 
:> du -h > dulist
:> 
:> Two more runs, one OK  with hammer mirror-stream over ssh NOT running, 
:> second  run with it mirroring a nearly empty dirtree (five static, 
:> one-line text files only), runs for several minutes, then drops into 
:> debugger with a mere three lines, rather than the original 
:> scrolled-off-the screen;
:> 
:> CRC DATA @ 9000000a3b15b280/128 FAILED
:> Debuger ("CRCFAILED: DATA")
:> Stopped at    Debugger+0x34:    movb    $0, in_Debugger.3970
:> 
:> But this does not seem to relate. Could be an NATACONTROL + old HHD I/O 
:> error artifact.
:> 
:> First looong err message had to do with vnodes..
:> 
:> More testing to do, then will swap-in a newer 500 GB SATA.
:> 
:> Bill

    Bill, could you be more precise on exactly which tests you are running?
    If I understand it you are doing some combination of bonnie++ and 
    mirroring but you are explicitly filling up the disk and allowing it
    to hit full-disk error conditions.

    It sounds like a test I should be running here, particularly if you
    managed to get a CRCFAILED panic out of it.  I want to try to reproduce
    that.

    It is possible that the CRCFAILED is due to an actual I/O screwup,
    since we're talking PATA drives here.  This could be particularly
    true if they are master/slave on the same controller.  However, my
    first assumption is that it is a software bug related to pounding
    it while it is full.

    Note that HAMMER is not designed to run on an 8GB partition.  The
    minimum is 50GB.  That said, HAMMER should never get a CRC error
    even if running on an 8GB partition.  So I want to track it down.

						-Matt