From owner-freebsd-arch  Mon Jan 22 19:32:52 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184])
	by hub.freebsd.org (Postfix) with ESMTP
	id 626C837B401; Mon, 22 Jan 2001 19:32:34 -0800 (PST)
Received: from beastie.mckusick.com (localhost [127.0.0.1])
	by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id RAA35771;
	Mon, 22 Jan 2001 17:47:44 -0800 (PST)
	(envelope-from mckusick@beastie.mckusick.com)
Message-Id: <200101230147.RAA35771@beastie.mckusick.com>
To: Matt Dillon <dillon@earth.backplane.com>
Subject: Fsck updates for filesystem
Cc: Ian Dowse <iedowse@maths.tcd.ie>,
	Alfred Perlstein <bright@wintelcom.net>,
	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
In-Reply-To: Your message of "Fri, 19 Jan 2001 13:02:15 PST."
             <200101192102.f0JL2F698129@earth.backplane.com> 
Date: Mon, 22 Jan 2001 17:47:44 -0800
From: Kirk McKusick <mckusick@mckusick.com>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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).

	Kirk


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message