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.ecn.uoknor.edu!paladin.american.edu!gatech!newsfeed.internetmci.com!news.mathworks.com!fu-berlin.de!news.belwue.de!news.uni-stuttgart.de!uni-regensburg.de!newsserv.uni-bayreuth.de!news.tu-chemnitz.de!fachat From: fachat@physik.tu-chemnitz.de (Andre Fachat) 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: 1 Apr 1996 12:35:33 GMT Organization: University of Technology Chemnitz, FRG Lines: 56 Message-ID: <4joiil$r75@narses.hrz.tu-chemnitz.de> References: <4hptj4$cf4@cville-srv.wam.umd.edu> <3140C968.20699696@netcom.com> <4istou$ri9@floyd.sw.oz.au> <4j0bmo$ftv@park.uvsc.edu> <jlemonDoqBq5.1Bx@netcom.com> <4jerrj$f12@park.uvsc.edu> NNTP-Posting-Host: digedag.physik.tu-chemnitz.de X-Newsreader: TIN [version 1.2 PL2] Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20397 comp.unix.bsd.freebsd.misc:16398 Terry Lambert (terry@lambert.org) wrote: : jlemon@netcom.com (Jonathan Lemon) wrote: : ] Hm. Shells just look at the inode to see if the file is executable, : ] in order to add it to the hash list. So what if there's some (unspecified) : For a "binary" that was a directory, there is a need to search : every directory in every directory in the path for "a.out" or : whatever you call your actual non-fork binary. You need to search only _one_ directory for a.out - the one directory with the name of the program you want to start. Only for each program execution, there is One more directory search, in a (assumption) small bundle directory. But then the linear search for a file in a directory is, IMHO a hack and should be replaced by something fast like binary tree or so... (when talking about performance problems.) : This is geometrically more time consuming than simply searching only : directories in the path, to a single iteration level. This is not as time-consuming, as everything still works as ususal. Just when directly accessing the executable, ld.so is doing an additional search in the bundle directory - that shouldn't slow down that much, as I said before. : Shell hashing is only one example. Another example is that an : a.out from an "executable" could land in lost+found, losing : its association with the program it belongs to. This is an : impossible situation with EA's, which have a single focal file : system object that is treated atmoically by the underlying FS : code -- unlike "a.out" files in "binary" directories. This is a point to think about. But then, most filesystem corruption comes from not written (meta)data when writing something to disk. Normal operation should not write something to a binary... How do you handle the "signle focal file system object" in a Unix filesystem. Is is a "Unix-File" with a builtin structure that contains fields for EAs, binaries...? You then also have to search the file for the binary field when executing (see above). Are the EAs stored in a special block, that is pointed to by something in the standard inode? Then this special block can get lost like any other block. : Simplicity isn't a good argument for using directories as files : in order to get resource forks Jonathan. Try another one. Should I flame? No, it's not worth it... Andre -- Andre Fachat, Tel:++49-371-531-3551|"I do not feel obliged to believe that the Stadlerstr 17, 09126 Chemnitz, FRG | same God who has endowed us with sense, a.fachat@physik.tu-chemnitz.de | reason, and intellect has intended us to http://www.tu-chemnitz.de/~fachat | forego their use" -- Galileo Galilei