cvs commit: src/sys/ufs/ffs ffs_alloc.c

[Pawel Jakub Dawidek]

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.

Not sure how much the problem I'm seeing is related to this, but after
clean reboot, when I do:

	# mount -u -r /usr

I get: /usr: update error: blocks 24 files 1

Any idea what's going on? This file system is using soft-updates.
Maybe it remounts itself to read-only before flushing buffers?

Not sure how old is the problem, but could be very old. Before GEOM
device was always open RW, now RO means RO and the order could be
wrong somewhere.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20051027/7ed5d030/attachment.bin