DragonFly users List (threaded) for 2009-02
DragonFly BSD
DragonFly users List (threaded) for 2009-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

BFBI OTT bug or limitation?

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Mon, 23 Feb 2009 16:50:43 +0800

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.


Target box:

VIA C7, 2 GB DDR2-533


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'.


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?


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]