Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Oct 2005 15:33:48 -0700 (PDT)
From:      Don Lewis <truckman@FreeBSD.org>
To:        kris@obsecurity.org
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/ufs/ffs ffs_alloc.c
Message-ID:  <200510032233.j93MXnvc019498@gw.catspoiler.org>
In-Reply-To: <20051003221608.GA98675@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On  3 Oct, Kris Kennaway wrote:
> On Mon, Oct 03, 2005 at 09:57:43PM +0000, Don Lewis wrote:
>> truckman    2005-10-03 21:57:43 UTC
>> 
>>   FreeBSD src repository
>> 
>>   Modified files:
>>     sys/ufs/ffs          ffs_alloc.c 
>>   Log:
>>   Initialize the inode i_flag field in ffs_valloc() to clean up any
>>   stale flag bits left over from before the inode was recycled.
>>   
>>   Without this change, a leftover IN_SPACECOUNTED flag could prevent
>>   softdep_freefile() and softdep_releasefile() from incrementing
>>   fs_pendinginodes.  Because handle_workitem_freefile() unconditionally
>>   decrements fs_pendinginodes, a negative value could be reported at
>>   file system unmount time with a message like:
>>           unmount pending error: blocks 0 files -3
>>   The pending block count in fs_pendingblocks could also be negative
>>   for similar reasons.  These errors can cause the data returned by
>>   statfs() to be slightly incorrect.  Some other cleanup code in
>>   softdep_releasefile() could also be incorrectly bypassed.
>>   
>>   MFC after:      3 days
> 
> Yeah!
> 
> This also affects 5.x, by the way.

Probably 4.x as well.  I'm planning on MFC'ing this all the way back
once it has aged sufficiently.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510032233.j93MXnvc019498>