Date: Thu, 15 Oct 1998 01:56:54 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?=) Cc: current@FreeBSD.ORG Subject: Re: SoftUpdates anomaly: what happens when you 'mount -u -o ro /usr'? Message-ID: <199810150156.SAA17973@usr04.primenet.com> In-Reply-To: <xzpvhlnfaii.fsf@bombur.ifi.uio.no> from "Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?=" at Oct 14, 98 05:06:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
What happens is that dependent data on the FS itself gets written out, but depedent data on the device vnode that the FS is mounted on does not. Basically, this is a systemic problem which has not been addressed, and it's the primary reason soft updates is a tunefs parameter instead of a mount option. I basically think that this is the wrong implementation, and I have argued with both Kirk and Julian about it on occasion (my personal take is that the act of a mount update should in fact unmount and then remount the device, syncing all buffers on the unmount). If you explicitly unmount the partition, then re-mount it, I believe it should work (obviously, you will have to try this with a partition other than /usr). The place to hide this is in the kernel in the common mount code, and then to instance the mounts seperately from their mappings into the FS hierarchy, so that the FS specific mount code can get a hell of a lot more simple. This turns a -o into a call to the FS specific unmount, then the FS specific mount, while leaving the objects allocated on the FS intact (it becomes the job of the common mount code to do the object destruction). The only wierd thing this implies is that, if the FS is managing it's own vnode pool, that there be seperate entry points for initialization and destruction of the pool, other than the ones that would have been implied by the mount/unmount. This is only an issue for things like CODA and TFS, so it's not a worry that has to be dealt with immediately. > I woke up to find my nightly doc build had failed due to a full /usr > partition. It's a 256MB partition with 160MB of data on it, so there > had to be a catch somewhere. I ran 'fsck -n' which revealed 13,500 > unreferenced files. Sounds like the soft clock had not had an opportunity to drain. You should have done a vmstat to see how many soft updates buffers were in use, and if the number was decreasing, or if there was a real problem (for a mounted FS with uncommitted softclock contents, what you saw is pretty much expected behaviour). > Now looking through the fsck output (I scripted it) it seems that the > unreferenced files were mostly binaries, and I bet if I looked closer > I'd find out the mtimes are consistent with days I've run make world. > What's more, I'm not missing any files; my bet is that the > unreferenced files are files which have been deleted (replaced) by > installworld. They're unreferenced because they were unlinked, but for > some reason they were never freed. I think somebody with more fs > experience than I have should take a look at what happens to a > softupdates fs when it is switched from rw to ro. It seems obvious to > me that pending writes should be flushed; it also appears that this > doesn't actually happen. This may be a real dependency issue, actually, or it may just be that the programs were used in the buildworld, and were still cached, so the cache was holding a reference on them, and they would eventually go away. I would be kind of surprised if there were a real dependency issue, unless the recent vfs_subr.c changes were at fault. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810150156.SAA17973>