Return to BSD News archive
#! rnews 11550 bsd
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!newsfeed.internetmci.com!in2.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: Thu, 18 Apr 1996 15:06:52 -0700
Organization: Me
Lines: 255
Message-ID: <3176BCFC.154575ED@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>
<31740EB4.20617DC8@lambert.org> <199604181734.SAA04797@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:21895 comp.unix.bsd.freebsd.misc:17787
Ray Auchterlounie wrote:
] >To be blunt: why do you want to manipulate EA's with existing
] >tools?
]
] To be even more blunt: Because its f***ing difficult to manipulate
] them with tools that _don't_ exist !
Since you are building EA's, don't you suppose that you would
build access methodologies at the same time? EA's don't exist
either. "it's f***ing difficult to manipulate something that
doesn't exist with tools which do exist".
] >When you add an EA, you are adding something supranormal --
] >something that you could not use an existing tool on in the
] >first place.
]
] EAs are data streams on disk. Data with all sorts of interesting
] effects maybe, but still data.
You are (erroneously) assuming implementation.
Is the file ownership an attribute? Yes. Is it a "data stream
on disk"? No. Does it work despite your objections? Yes.
] We have a legion of existing tools to manipulate data streams in the
] form of _files_. Map EAs to files and all these tools are available,
] don't do it and all these tools are broken. Many of the programs that
] would need fixing aren't yours or mine to fix.
Much of what would constitute the space of "useful EA's" is a
collection of *state information*, not a collection of data
streams. State information that is sometimes the result of
file system events and is *read only* to the user.
Try setting the file attribute "size" without changing the
block allocation list.
The only thing "extended" about "extended attributes" is that
it is possible to implement attributes which don't currently
exist. In other words, it is a more flexible framework than
the inode. It is not, however, fundamanetally different.
If you want to have the EA's exported in the FS name space,
fine: implement them as unexported in the underlying FS
framework, and implement their export as a loopback mount
of a Heidemann framework stacking layer. This would be a
trivial change to the existing NULLFS module, as supplied
with the 4.4BSD-Lite2 FS code.
You are confusing exposed namespace and implementation. This
is a fundamental error in your approach.
] >Exposing attributes in the FS namespace seems silly. To do so
] >requires duplicating access control semantics for each EA to
] [...]
] Either EAs have separate access control or they dont (inheriting that
] of the file) - if they do it needs storing, if they dont it doesn't.
If they are seperately exposed, then their existance in the
namespace is not atomic by virtue of the manipulation of the
namespace itself being a potentially non-idempotent event
(unless you dictate logging, trasaction tracking, and error
correction in your implementation of name space manipulations).
This means that there is potentiall for non-idempotence in a
failure situation. Thus each EA mush come with association
information to allow idempotent recovery outside the scope of
the attribute name space manipulation semantics.
Ie: you have to add a bunch of crap for each attribute to
implement inheritance if you don't add a bunch of crap to
implement those things that you want to inherit instead
of adding them.
Either way, the implementation is fundamentally flawed without
recourse to a *massive* increase in complexity -- all to get
the "benefit" of kludging legacy code to work.
Again, better to write a loopback module and reexport it to
get your legacy code running.
] >I agree with your division between imlementation and access
] >issues, but I disagree that these are reconcilable differences.
]
] Is that disagree that they _can_ be reconciled or that they _should_ ?
I disagree that they _can_ be reconciled without a massive
increase in complexity of the underlying implementation, and
I disagree that a massive increase in complexity _should_
take place soley for the benefit of legacy applications,
when you can get your name space exposure in a much, much
simpler way, and without linking it to the implementation.
] >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.
]
] What about the _data_ "default icon" (be it a filename, xpm data or
] whatever). What happens to this _data_ when I backup my system using
] tar/cpio/afio/proprietary-backup-program ?
] Ok, so you need a new set of backup programs. That's only the
] start. By the time joeuser has finished inventing uses for EAs
] you and I never dreamed of, you need a new _everything_.
You implement a loopback for name space exposure for these legacy
backup applications. You discard the loopback when it is no
longer necessary (when the legacy apps have been displaced).
] Examples, just from my experience with _existing_ systems:
]
] 1. ext2fs on Linux:
]
] Has extended file attributes, secure deletion, append-only, etc.
] Tools are provided of course, lsattr and chattr.
]
] Backup ? - bye bye attributes.
] Move file to another file system and back ? - bye bye attributes.
] NFS mount ? - no access to attributes.
] Supported in file-managers/browsers ? - not that I've seen
] Result ? - little known or used
Obviously, you are missing any real loopback technology.
As far as moving to another file system, it is possible to expose
the same semantics, with the potential for error that has already
been explained in the file-as-directory portion of this thread,
by loopback mounting.
A very, vey simple version of this idea is the UMSDOS file
--LINUX-.--- (why wasn't it -UMSDOS-.---???), which "loopback"
mounts the DOS FS, stealing, via namespace intrusion, and
without the byte-stuffing of a real implementation, to add
"extended" attributes to a file system which does not normally
support them. It has the "hosted FS" risk of a DOS user
coming in and breaking the association between the --LINUX-.---
file and the directory to which it refers. It also has the
non-atomicity synchronization risks, since DOS and --LINUX-.---
directory entry manipulations are not idempotent for a given
file.
] 2. Netware (DOS clients):
]
] Has file permissions, trustee lists, ownership etc., tools to
] access and change these are provided of course. But existing
] tools can't.
]
] Editors would let you open and edit a file you only had read access
] to. Some would die (lose your work) when you then tried to
] save. Fixing (even the ones I had source for) proved almost
] impossible. I fixed Demacs (this was years ago) - the fix involved
] shelling out to DOS and calling "rights" and parsing the output, for
] every file opened. Now who's talking horrible kludges ? (and yes
] please tell me a better way).
Well, when I was at Novell working in the implementation of
the NetWare for UNIX 4.x server and the attributed file
system that shipped with it back in 1994 (hmmm... been doing
this sort of coding for a while, Terry? Hit all these issues
before, Terry?), we dealt with it by administrative fiat and
attribute mapping. One attribution space was considered
primary, and all others were secondary.
In point of fact, you can not coelesce all access control
models into a single model successfully if the models use
fundamentally different paradigms.
A POSIX compliant system supports only advisory locking of
ranges in files -- how do you enforce NetWare mandatory
locking semantics against UNIX clients which have no API
wherein they can make mandatory locking requests? The very
existance of the need to IPC lock check/usage order sync
for UNIX processes using advisory locking makes it impossible
to enforce the semantics on an application which does not
voluntarily obey them.
Specifically, the allowable behaviours for applications which
may succcessfully interoperate is a subset of the API's
available to applications in both API spaces. Only if you
restrict yourself to interoperating with clients in a
single API space can your application full map that space.
] Existing backup tools couldn't save this information. No problem
] - we got a (proprietary $$$) netware-aware backup tool. It
] managed to get <10% of the data rate to tape that tar could -
] unusably slow, took a lot of man hours to get (fudge) a fix.
Oh well. Your choice to use NetWare in a mixed environment.
You can live with bad administrative decisions, or you can own
up to them and correct them, but it's impossible to correct
them while you are pretending that the initial decision was
never bad in the first place.
If you change to a non-mixed environment of one kind or the
other, you won't have these problems.
] Maybe our dat drive isn't right - lets try backup over the
] network to shared dat on a unix box, no problem, just use tar.
] Hey, why did we buy a dat at all ? Oh yeah, no attributes in
] tar backup, bollocks.
I don't see how this would lead you to buy a DAT drive, but
then I can't envision a sane decision making process winding
up with a mixed environment without considering the trade-offs
before the decision is irrevocable, either.
] 3. Now an example of how it perhaps should be done:
]
] Modern macs can access dos floppies, want to take your work from a mac
] home to your PC ? - no problem. Hey, what's this funny RESOURCE.FRK
] directory and all the strange stuff in there. What use is copying the
] mac resource fork if it's going to a PC ???
]
] Take file home from mac to PC, view/edit the _file_, then go back to
] the mac. Hey, neat, it remembers what type the file is...
]
] I can think of more.
I can think of counter examples, where there is implied state
(implied by the Mac program) between the resource and data fork
contents, where changing the data fork contents will cause
an inconsistency to come into existance.
Your example only works in a small subset of the cases, where
the attributes aren't an integral part of the functioning of
the applications... try the same thing with Word Perfect 5.x
documents, for example.
I think this name space exposure issue has been beaten to
death: it is possible to provide it optionally to people
who are willing to update kernel components and disk images,
but insist on installing legacy tools. I don't think that
is the case that should be optimized at the expense of
design flexibility and robustness.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.