Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!hobyah.cc.uq.oz.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.hawaii.edu!ames!agate!howland.reston.ans.net!swrinde!gatech!newsfeed.internetmci.com!in1.uu.net!news.artisoft.com!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Subject: Re: Ideal filesystem
Date: Tue, 16 Apr 1996 14:18:44 -0700
Organization: Me
Lines: 91
Message-ID: <31740EB4.20617DC8@lambert.org>
References: <4hptj4$cf4@cville-srv.wam.umd.edu> <4jpjb6$77c@park.uvsc.edu> <jlemonDpEw1v.4Ez@netcom.com> <4kfoqd$dgs@coyote.Artisoft.COM> <DpvCB7.xn@midway.uchicago.edu> <199604161704.SAA02116@kythera.demon.co.uk>
NNTP-Posting-Host: hecate.artisoft.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.01 (X11; I; Linux 1.1.76 i486)
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21530 comp.unix.bsd.freebsd.misc:17474
Ray Auchterlounie wrote:
] Which brings me onto the main point I want to throw into the debate:
] there seems (to me) to be a lot to be gained by making a distinction
] between filesystem _implementation_ and _appearance/interface/API/?_.
]
] Most (all ?) of the arguments against adding EAs to the filesystem
] have been about compatibility with existing tools which use the fs -
] this is an interface issue. Whereas the arguments _for_ have been
] about atomicity, tight binding of file-forks, (with extra comments on
] log-structuring, journaling etc.) - all implementation issues.
]
] Speculation: most of those supporting file-as-directory wouldn't
] actually care if EAs weren't implemented that way _provided_ they
] could be made to _appear_ that way if desired. They simply want
] EAs to be done in a way that allows existing tools to use them. I
] have to admit I agree - ext2fs has some EAs already (immutable
] etc.), but they are little known/used and I suspect this is
] because they can only be listed/modified using special tools.
]
] I would like EAs that I can:
] list/edit, using cat/ls/ed/vi/emacs...
] search, using grep/awk/perl...
] backup, using tar/cpio/afio...
] etc. etc.
]
] If we separate the implementation from the interface using "views"
] "translators" or whatever, then everyone can be happy. Implement EAs
] however you want, (for whatever reasons) and provide a set of
] interfaces to allow people to access them however they want.
To be blunt: why do you want to manipulate EA's with existing
tools?
When you add an EA, you are adding something supranormal --
something that you could not use an existing tool on in the
first place.
Exposing attributes in the FS namespace seems silly. To do so
requires duplicating access control semantics for each EA to
get it back to the level of control available to normal FS
objects: owner, group, permissions, etc.. You end up needing
nearly as much information as you do for a regular file.
I agree with your division between imlementation and access
issues, but I disagree that these are reconcilable differences.
To put this another way: I can't edit the default icon for
an application now with existing tools, so I need not support
that type of access for the association "default icon" in a
new implementation.
I have already done a "file as directory" implementation for
executables; it's easy to do the same thing, with implied
fork "data", for files as well. In FreeBSD, I can do a
hybrid version of this in about 30 minutes (given that I
still have the code for the exec loader) using a NULLFS
and terminal component name space intrusion. It's a
*trivial* hack, and doesn't speak to the implementation
issues at all... *can't* speak to them.
] Ideal filesystem ?
] ...one which is capable of being all things to all persons.
Which is why I wanted to start with a flat (numeric) namespace
with a variable granularity block store, then implement FS
objects and events on top of that -- including the concept of
directory hierarchy.
I believe that imposing "normal" access semantics for objects
which have not previously existed (and therefore do not require
"normal access semantics") is too big a restriction to allow
any kind of truly novel innovation. From that perspective,
the Plan 9 device pardigm is impossible to implement, for one
thing, and a devfs is impossible to implement if special device
support is to be built into each possible FS type.
I'd like to see existing restriction struck down, not codified.
This may in fact be frightening to people with a large
investemnt in code that makes assumptions about allowable
behaviours. That's unfortunate, but is part of the price
we must pay for capabilities which weren't there before.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.