Date: Thu, 27 Oct 2005 09:08:58 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Don Lewis <truckman@FreeBSD.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: <20051027070858.GA641@garage.freebsd.pl> In-Reply-To: <20051027065505.GA668@garage.freebsd.pl> References: <200510032157.j93LvhM7022905@repoman.freebsd.org> <20051027065505.GA668@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
--pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 27, 2005 at 08:55:46AM +0200, Pawel Jakub Dawidek wrote: +> On Mon, Oct 03, 2005 at 09:57:43PM +0000, Don Lewis wrote: +> +> truckman 2005-10-03 21:57:43 UTC +> +>=20 +> +> FreeBSD src repository +> +>=20 +> +> Modified files: +> +> sys/ufs/ffs ffs_alloc.c=20 +> +> 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. +> +> =20 +> +> Without this change, a leftover IN_SPACECOUNTED flag could prevent +> +> softdep_freefile() and softdep_releasefile() from incrementing +> +> fs_pendinginodes. Because handle_workitem_freefile() unconditional= ly +> +> 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. +>=20 +> Not sure how much the problem I'm seeing is related to this, but after +> clean reboot, when I do: +>=20 +> # mount -u -r /usr +>=20 +> I get: /usr: update error: blocks 24 files 1 +>=20 +> Any idea what's going on? This file system is using soft-updates. +> Maybe it remounts itself to read-only before flushing buffers? +>=20 +> 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. I fsck'ed this "clean" file system and: ** Phase 4 - Check Reference Counts UNREF FILE I=3D2357670 OWNER=3Dpjd MODE=3D100600 SIZE=3D258 MTIME=3DOct 27 08:40 2005 CLEAR? [yn] y UNREF FILE I=3D8101888 OWNER=3Droot MODE=3D100644 SIZE=3D10573 MTIME=3DOct 27 08:41 2005 CLEAR? [yn] y UNREF FILE I=3D8102436 OWNER=3Droot MODE=3D100644 SIZE=3D10573 MTIME=3DOct 21 12:04 2005 CLEAR? [yn] y ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? [yn] y SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 887288 files, 28777941 used, 3987616 free (251064 frags, 467069 blocks, 0.8= % fra gmentation) ***** FILE SYSTEM WAS MODIFIED ***** Doing: # sync;sync;sync;mount -u -r /usr worked just fine when I tried. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDYH0KForvXbEpPzQRAobeAJ9qdsQ532+FTApByGDBpBPiQ2THIQCg96zE YqGXjUYZ20FCs1x3dy/AJ38= =i6+0 -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051027070858.GA641>