Date: Wed, 3 Jun 1998 10:33:45 -0500 From: "Alton, Matthew" <Matthew.Alton@anheuser-busch.com> To: "'hackers@FreeBSD.ORG'" <hackers@FreeBSD.ORG>, "'FreeBSD-fs@FreeBSD.ORG'" <FreeBSD-fs@FreeBSD.ORG> Cc: "Smallie, Scott" <Scott.Smallie@anheuser-busch.com> Subject: Filesystem Development Toolkit Message-ID: <31B3F0BF1C40D11192A700805FD48BF9017765D7@STLABCEXG011>
next in thread | raw e-mail | index | archive | help
Hackers,
My recent excursions into the wonderful world of filesystem development
have led me to embark on the following Mondo Project which is currently in the
lex-spec + stubs phase. The project spec follows. Well, it started out as one
anyway, but turned into a sort of polemic rant. I wrote it in the throes of
trad-
itional development :-) Please help me come up with good ideas.
Yes, I'm going to copyleft the software. I just can't stand the thought
of
Bill's henchmen holding my slightly modified code hostage in their nasty ten-
tacles.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$Id: SPEC,v 1.3 1998/06/03 00:09:30 matta Exp matta $
Filesystem Development Toolkit
==============================
The Filesystem Development Toolkit (FDT) is software designed to ease the task
of implementing, testing, and debugging filesystem designs.
Traditional filesystem development is unduly complex. The procedure involves:
1) Design phase - The fundamental structure and properties of the filesystem
are defined;
2) Coding - The filesystem code and operating system kernel interface code
are written;
3) Testing - The filesystem modules are loaded into system space and run with
superuser privileges;
4) Debugging - Problems detected in the testing phase are traced to root
causes in the coding and/or design phases and are remedied.
This procedure is fraught with alleviable difficulties. The coding phase nec-
essarily involves a detailed knowledge of the inner workings of a specific oper-
ating system. Such knowledge is often irrelevant to the purpose of the develop-
ment effort. The filesystem interface particulars vary radically between oper-
ating systems so that the code must be altered substantially for each new de-
velopment platform. Testing new filesystem code invariably involves destabil-
izing the operating system running on the test platform so that a machine must
be dedicated to testing. The debugging phase is egregiously difficult as oper-
ating system debugging is inherently more difficult than application debugging.
Each cycle of the process may necessitate a reinstallation of the operating
system due to media corruption caused by buggy filesystem code. A non-root
user is not able to test a new filesystem design at all. Many of these problems
are rendered geometrically more difficult when the filesystem in question is of
the distributed variety and requires multiple network nodes for testing pur-
poses.
All of these difficulties may be relieved to various degrees by simply moving
the development cycle entirely into user space. The difficulty involved in
developing a new filesystem would then be on the order of that involved in app-
lication development. The problem of "porting" the new filesystem to another
operating system, while still difficult, would at least be distinct from the
development cycle.
The FDT provides a simulation environment for developing filesystems in user
space by effectively "stepping down" the levels of the operating system. The
filesystem under development actually exists as a regular file which the FDT
manipulates. This regular file is in effect a "disk image" containing a bit-
for-bit likeness of an instance of the filesystem under development. The FDT
provides the layer of abstraction necessary to create filesystem objects in the
disk image. Concurrent access may be controlled through file permissions and
... ... ...
sfc - Simulation Fileystem Control program. Command-line interface for use
in filesystem prototyping.
Commands:
![cmd [args ...] ] - Shell command.
Execute cmd in a subshell.
mkpf < -s size pf_name > - Make prototype file.
Create a zero-filled file named `pf_name' of `size' bytes analogous to
a mass storage device.
mkfs < pf_name > - Make file system.
Create a bit-pattern analogous to a filesystem on the prototype file
named `pf_name'.
mount_lfs < pf_name > - Mount file system.
Reset `pf_name' clean bit and enable read and write operations on
`pf_name'. Analogous to mounting filesystem named `pf_name' on
mount point `pf_name'.
fsck < pf_name > - File system check.
Check and optionally attempt to correct inconsistencies in bit-pattern
on file `pf_name'.
df [ pf_name [ pf_name ... ] ] - Summarize disk free space.
Display summary of free space per prototype file argument.
du [ pf_name [ pf_name ... ] ] - Summarize disk usage.
Display summary of space usage per prototype file.
cp < source dest > - Copy filesystem object from source to dest.
`source' and `dest' may be files or bit-patterns within a prototype
file.
mv < source dest > - Move filesystem object from source to dest.
`source' and `dest' may be files or bit-patterns within a prototype
file.
mknod < node b|c|u major minor > - Make device special file.
Make
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Matthew Alton
Computer Services - UNIX Systems Administration
(314)632-6644 matthew.alton@anheuser-busch.com
alton@plantnet.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31B3F0BF1C40D11192A700805FD48BF9017765D7>