Date: Tue, 23 Jan 2001 10:56:37 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Kirk McKusick <mckusick@mckusick.com> Cc: Matt Dillon <dillon@earth.backplane.com>, Ian Dowse <iedowse@maths.tcd.ie>, Mike Smith <msmith@FreeBSD.org>, Tony Finch <dot@dotat.at>, Terry Lambert <tlambert@primenet.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.org Subject: Re: Fsck updates for filesystem Message-ID: <20010123105637.U26076@fw.wintelcom.net> In-Reply-To: <200101230147.RAA35771@beastie.mckusick.com>; from mckusick@mckusick.com on Mon, Jan 22, 2001 at 05:47:44PM -0800 References: <200101192102.f0JL2F698129@earth.backplane.com> <200101230147.RAA35771@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Kirk McKusick <mckusick@mckusick.com> [010122 19:32] wrote: > There have been several suggestions on where to put the hooks for > fsck to update a running filesystem: ioctl, mount, fcntl, and sysctl. > As several folks pointed out, we are dealing with filesystem incore > data, so ioctl is quite inappropriate as it really wants to deal > with the underlying disk (the disk knows nothing about the > filesystem data structures that are stored on it). Mount is possible, > but dubious, because it has such bizzare semantics already which > would be tricky to work around and most of which are at best > unnecessary for the problem at hand. I lean against fcntl as its > current functions are all things that are typically done by normal > user programs. It has no kernel administration functions associated > with it, and I believe that documenting them in the fcntl manual > page will only lead to generally useless bloat in a page intended > for relatively naive users. In addition it would be a non-standard > extension to a POSIX defined interface. So, I am still of the > opinion that sysctl is the right place for these functions. Like > many other sysctl's, fsck want to manage kernel state. The correct > administrative controls are already in place (checking for root). > The framework extends in an obvious place (kern.vfs.ffs.<func> > where <func> is one of adjlinkcnt, adjblockcnt, or setblockmap). > A final evidence of correctness is that all the needed functionality > for the above three functions adds a grand total of 40 lines to > the kernel (including three sysctl definitions, comments, and code). I agree with the sysctl approach, along with your patch for making sysctl oid's non-repeating (although it could use a mpfixme() because of the global counter). So just commit it, I'll do the lock around the counter later. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010123105637.U26076>