BFBI OTT bug or limitation?

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Brute Force and Bloody Ignorance is Over The Top when;

'du -h'

saves keystrokes over:

'shutdown now'

Likewise a few other ways to either reboot or drop into the debugger.

Environment:

Target box:

VIA C7, 2 GB DDR2-533

2 X IBM 60GB PATA as NATACONTROL RAID1

2.3.0. 'default install' to all-HAMMER

root-mounted /slave1 PFS-created as such by hammer mirror-copy over ssh


Source box:

Lenovo G400 3000 laptop. 33GB slice ad0s1 for DFLY.

2.2.0 Installed to UFS, spare 8 GB partition *ONLY* later formatted and 
mounted as hammerfs '/hmr', made into a master for testing, '/hmr/master'.

ACTION:

hammer mirror-stream /hmr/master Thor@<target_IP>/slave1
over ssh 100 Mbps internal link.

Fire-off bonnie++ to fill the /hmr partition with fairly deep recursion.
It fills and stops gracefully with a ...cannot write' message, begins to 
cleanup its work area.

meanwhile, the ssh link has been doing its best - and it's best is very 
good.

Watching the target sees ~/slave1 gradually clear as bonnie++ mops up 
the master, until back where du shows zero usage, slaves having no 
snapshots of their own.

But the /hmr/master mount has gone from zero to 94% used, and the target 
has gone from 76% used to 87% used.

'du' on the master cannot seem to locate where TF the '94%' df reports 
for /hmr is hiding, but never mind.. we can nuke and newfs that 
partition at will.

But where is the used space on the *target* hiding?

'du -h /' on the all-hammerfs target *reboots* it soemwhere along the way.

. .  Comes back up quick - I'll give it that...

But hang-on.  Could an 'ordinary user do that at will?

'du -h > dulist' (for later grep'ing) throws a panic and drops DFLY into 
the debugger...

Also worrisome...

By comparison, a UFS fs when overloaded, ordinarily soldiers on with 
109% utilized and a 'no space on device' message. For days....

Hammer needs to get there also...

If this is an out-of-memory situation with 2GB, it shouldn't be.

If the fs is full, the exit should be graceful, not catastrophic.

If no one else can reproduce this, I'll try it on other hardware - and 
with a serial terminal.

NB: Rather small drives and partitions used. /hmr/master 8GB, entire 
hammer fs on target only 60 GB.

That part is intentional.

No need to wait all day to see if it happens on a half-terrabyte also.

Panic not captured. Do we need it, or is this a known issue?

Bill