Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.uwa.edu.au!disco.iinet.net.au!demeter.omen.com.au!news.it.com.au!nexus.it.com.au!nexus.it.com.au!not-for-mail From: sjm@it.com.au (Simon Mackinlay) Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Subject: Re: Ideal filesystem Followup-To: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Date: 11 Apr 1996 16:28:30 +0800 Organization: Deliberately disorganised. Lines: 58 Message-ID: <4kifre$q0l@nexus.it.com.au> References: <4gejrb$ogj@floyd.sw.oz.au> <3140C968.20699696@netcom.com> <4ia7im$i4m@usenet.srv.cis.pitt.edu> <4if9gb$4kh@park.uvsc.edu> <4iibd2$ng@EARTH.baylor.edu> <4ir7tc$5uf@park.uvsc.edu> <31530CC6.266C03EF@ids2.idsonline.com> <4j0ccn$ftv@park.uvsc.edu> <4jthcs$3dn@nexus.it.com.au> <31631263.68EFE48C@netcom.com> NNTP-Posting-Host: localhost X-Newsreader: TIN [UNIX 1.3 950515BETA PL0] Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21151 comp.unix.bsd.freebsd.misc:17135 [On cold.system, Adam Megacz (kalessin@netcom.com) bellowed unto all...] > I have 3: > > 1) Elegance. If EA's are part of the filesystem, I can use all > those fun preexisting apps (cat, tar, cp, mv, ls) to manipulate them. > Not to mention stuff like xfilemanager. Ever seen (at the risk of earning flamage) WinNT's registry editor? Again, I'm willing to learn from other people here - but if application specific meta data is stored in a database, then it's easier to manipulate them - whether querying, duplicating, or backing them up? Sure, you'll need Yet Another Administration tool to administer your metadata; but you could use one tool to administer _all_ of your configuration files, in such a system. Hacking passwd, group, crontab, ypconfig, inn.config, ad nauseum _could_ be a ancient nightmare, with minimal breakage. > 2) Consistency. If the metadata is manipulated by a library, and I > rename or copy a file that has metadata attached to it, I've just > orphaned the metadata. If metadata is manipulated by a library, then the names of files, whether data or application, becomes irrelevant, surely? The metadata is now under control of the application, the way it's stored on disk is no longer an issue. > 3) The UNIX way (tm). It seems (IMHO) that integrating everything > into the filesystem is the UNIX way (tm). I really like it, and there > are others that do, too. This is a philosophical point, and I'd very much like to disagree with you here; As far as _I_ can tell, the UNIX way (tm) is simplicity; the device driver drives devices; the filing system stores files; the c library does buffered and formatted io; ls is not a web browser. One level of abstraction per layer; metadata is application specific data, which surely can be maintained with the most degrees of freedom, and the widest degree of applicability with what's essentially a database engine? I'm not arguing with the need for discretionary ACL's; I feel that owner/group is not fine grained enough for access control. However, I'm still possibly just too myopic to see the need to store graphical data, configuration information, user preferences, et al, in invisble streams on disk. We're coming fairly rapidly to a simple agree-to-disgree here, and I'm aware of that, but as far as I can tell, the arguments _for_ a multi-streamed filing system have counterbalncing arguments against; What I'm suggesting is a rethink, that perhaps there's a better way to store application/user/system specific metadata than the ways presently being considered. -- Simon (sjm@it.com.au) strength through elegance /// beauty in intelligence