Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Jan 2001 17:47:44 -0800
From:      Kirk McKusick <mckusick@mckusick.com>
To:        Matt Dillon <dillon@earth.backplane.com>
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
Subject:   Fsck updates for filesystem
Message-ID:  <200101230147.RAA35771@beastie.mckusick.com>
In-Reply-To: Your message of "Fri, 19 Jan 2001 13:02:15 PST." <200101192102.f0JL2F698129@earth.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101230147.RAA35771>