In resize_ffs's source, there is a comment reading, in part,

 * XXX is there a bug lurking in the ignoring of block boundaries by
 *  the routine used by fragmove() in evict_data()?  Can an end-of-file
 *  frag legally straddle a block boundary?  If not, this should be
 *  cloned and fixed to stop at block boundaries for that use.  The
 *  current one may still be needed for csum info motion, in case that
 *  takes up more than a whole block (is the csum info allowed to begin
 *  partway through a block and continue into the following block?).

Having run into it now, I believe that the bug this comment alludes to
is present.  See the "blkfree: bad size" panic in ffs_blkfree() - the
fragnum()+numfrags()>fs->fs_frag condition is the one this is talking
about.

I don't have patches yet, and they wouldn't apply cleanly even if I did
because they'd be to the original source rather than the post-import
reformatted source.  But I thought a heads-up was in order, since
looking at the source makes me think even -current suffers from this.

The sumptom is that if you use resize_ffs to shrink a filesystem, it's
possible that attempts to remove certain files will trip the "blkfree:
bad size" panic.

This also indicates a bug in fsck, in that it should catch and repair
this condition.  (It doesn't in my tests, and while I have no easy way
to test it under -current, fsck is known to be sloppy about detecting
certain unlikely inconsistencies such as this, so I would expect it to
fail to catch this condition even in -current.)

If you suffer from this, copying the affected files to preserve their
contents, using clri on them, and using fsck to patch up the damage
*should* repair things.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B