Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.uoknor.edu!news.nodak.edu!netnews1.nwnet.net!news.u.washington.edu!uw-beaver!uhog.mit.edu!news.mathworks.com!gatech!sdd.hp.com!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Subject: Re: Ideal filesystem
Date: 9 Mar 1996 22:31:04 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 47
Message-ID: <4ht0r9$dfi@park.uvsc.edu>
References: <4gejrb$ogj@floyd.sw.oz.au> <4gilab$97u@park.uvsc.edu> <4giqu8$aqk@park.uvsc.edu> <4gira2$a9d@park.uvsc.edu> <hpa.31321eee.I.use.Linux@freya.yggdrasil.com> <4h7t5i$qoh@park.uvsc.edu> <DnoqB4.2sy@pe1chl.ampr.org> <glDH59i00YUvFFjspX@andrew.cmu.edu>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:18984 comp.unix.bsd.freebsd.misc:15157
G Sumner Hayes <sumner+@CMU.EDU> wrote:
] Sorry for the second post in rapid succession in reply to the same
] thread, but I thought it a good idea to break the two apart. If you
] were to start implementing a new general purpose filesystem under a
] Unix-like OS, what considerations would be important? What features
] would you find absolutely necessary? What would be nice to have?
]
] I'm considering the idea of implementing a new filesystem for one of
] the free Unices, but I'd like to know how much room for improvement
] there is over FFS/ext2fs and how daunting a task this would be. So
] I'm looking more for a "realistic" ideal filesystem than an impossibly
] perfect one, but difficult ideas are welcome . . .
There is a *lot* of room for improvement in file system
technology.
One good building block would be a variable granularity block
store with a flat name space on which you could impose hierarchy,
attribution, dirtectory management, inode, and directory storage
all seperately.
Another good building block would be a nice general order
scheduling mechanism based on the "soft updates" work that
could be incorporated into any FS. You would build a directed
dependency graph given all FS events, and you would insert them
into the processing list "soft update"-style using the order
node from the graph as an insertion point.
EachFS would register "node-to-node" reduction interfaces when
the graph was built. This would effectively provide all of
the Appendix A FS specific routines in such a way as to prevent
the soft update implementation from becoming FS dependent.
Basically, in combination, the mechanisms would provide a generic
replacement for a block I/o subsystem for use with a VFS
framwork (the big pain in the VFS definition is that the top
end has a defined interface (VOP), but the bottom end is little
more than a system-specific kludge.
This should take no more than 10 years to get right. 8-).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.