From owner-freebsd-arch Tue Jan 23 10:57: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1AB9C37B401; Tue, 23 Jan 2001 10:56:43 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0NIubW04982; Tue, 23 Jan 2001 10:56:37 -0800 (PST) Date: Tue, 23 Jan 2001 10:56:37 -0800 From: Alfred Perlstein To: Kirk McKusick Cc: Matt Dillon , Ian Dowse , Mike Smith , Tony Finch , Terry Lambert , Poul-Henning Kamp , arch@FreeBSD.org Subject: Re: Fsck updates for filesystem Message-ID: <20010123105637.U26076@fw.wintelcom.net> References: <200101192102.f0JL2F698129@earth.backplane.com> <200101230147.RAA35771@beastie.mckusick.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101230147.RAA35771@beastie.mckusick.com>; from mckusick@mckusick.com on Mon, Jan 22, 2001 at 05:47:44PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Kirk McKusick [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. > where 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