Date: Mon, 12 Oct 1998 14:32:12 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Terry Lambert <tlambert@primenet.com>, thomma@BayNetworks.COM (Tamiji Homma) Cc: freebsd-current@FreeBSD.ORG Subject: Re: installworld and softupdates Message-ID: <199810122132.OAA12453@salsa.gv.tsc.tdk.com> In-Reply-To: Terry Lambert <tlambert@primenet.com> "Re: installworld and softupdates" (Oct 8, 10:39pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 8, 10:39pm, Terry Lambert wrote: } Subject: Re: installworld and softupdates } Disk space held by uncommitted deletes depending on other operations } is, by definition, not reusable until such time as the operations are } committed. } } Another fix would be to explicitly call "sync" at the appropriate } places to ensure the soft clock is drained (and thus deleted file } space was recovered before it was needed. Calling sync() can be pretty costly, and you still need to wait for a while for all the I/O has actually drained. } You can see this in action very easily by copying a full X11 tree } to a soft updates parition, syncing it out, deleting it, and then } doing a "df" once a second and watching the space "drain back". I've heard of software (diablo?) being bitten by a feature like this, though I don't remember the OS. For whatever reason it decided that it was out of space and that it needed to deleted some "old stuff" to make room. It started deleting "old stuff" and checking the amount of free space available. The amount of free space didn't go up, so it kept on deleting, until it had nuked almost everything on the partition. It was only after a fairly long interval that the OS started reporting the space that had been freed. } The soft updates code should arguably advance the slot clock at } an accelerated rate in the case that new entries are not being } made. Feel free to submit code. 8-). IMHO, statfs() should report the amount of free space on the disk that will be there after all the pending filesystem updates are complete, just like stat() tells you a file is gone after it has been unlinked even though its directory entry and inode haven't yet been cleared on disk. If a process wants to claim disk space that has not yet been freed on disk, at worst the process should sleep. Heck, you might even be able to optimize out some free space bitmap writes in the case where you delete a file and create a new file of the same size. It's just a small matter of programming ... 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?199810122132.OAA12453>