kern/45982: LFS metadata space estimate can cause false "filesystem full" condition

[perseant%hhhh.org@localhost]

>Number:         45982
>Category:       kern
>Synopsis:       LFS metadata space estimate can cause false "filesystem full" 
>condition
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 11 06:15:01 +0000 2012
>Originator:     Konrad Schroder
>Release:        5.99.64 userland (including RUMP kernel) on 5.99.61 host
>Organization:
>Environment:
NetBSD wetbar.hitl.washington.edu 5.99.61 NetBSD 5.99.61 (GENERIC) #1: Sat Jan 
28 13:57:59 PST 2012  
perseant%wetbar.hitl.washington.edu@localhost:/alt/src-current/sys/arch/i386/compile/obj.i386/GENERIC
 i386

>Description:
Because LFS allocates metadata, specifically inode blocks, on an as-needed 
basis rather than pre-allocating them the way FFS does, it estimates how much 
of the rest of the disk *would* be filled with inode blocks, segment headers, 
and other metadata if usage continues the same as it has for the disk thus far, 
compared to the number of data blocks.

If the proportion of inode blocks is extreme---as it is for the t_renamerace 
test---the filesystem can report "full" even when there is almost nothing 
actually stored on the disk.
>How-To-Repeat:
Fix the crashy part of t_renamerace (see kern/43582), and then run 
"t_renamerace lfs_renamerace_dirs".
>Fix:
Use nonlinear mixing of the actual metadata use with the projection. When  the 
disk is empty, the sample size that generates the projection is small, and we 
should avoid reporting disk full; but when the disk approaches capacity, the 
projection is more accurate (assuming a uniform pattern of use) and it is more 
important to avoid reporting free space erroneously.