Return to BSD News archive
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.dca.gov.au!news.mel.aone.net.au!inferno.mpx.com.au!news.unimelb.EDU.AU!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!jlemon From: jlemon@netcom.com (Jonathan Lemon) Subject: Re: Ideal filesystem Message-ID: <jlemonDp1GFM.H4I@netcom.com> Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <4hptj4$cf4@cville-srv.wam.umd.edu> <4j0bmo$ftv@park.uvsc.edu> <jlemonDoqBq5.1Bx@netcom.com> <4jerrj$f12@park.uvsc.edu> Date: Fri, 29 Mar 1996 16:57:21 GMT Lines: 55 Sender: jlemon@netcom22.netcom.com Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20234 comp.unix.bsd.freebsd.misc:16224 In article <4jerrj$f12@park.uvsc.edu>, 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) >] bit or combination of bits in the inode that indicates this directory >] is an "executable bundle"? Then the search stops there. When 'executed', >] the system runs "(directory_name)/a.out" or even "(directory_name)/a.out.arch". > >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. Um, no. If the directory has an 'executable' bit, then the search stops there, and the the actual binary within the directory is _assumed_. This gives the same behavior that we have today. (yes, the actual binary may not be present - this would be discovered when the user attempts to execute the program, and would be handled the same way as a corrupted binary) > >This is geometrically more time consuming than simply searching only >directories in the path, to a single iteration level. no - see above. > >Using directories as binaries has the singular benefit that >you can abuse the file system in the same way the terminfo >database abuses thefile system to use the directory structure >as an index. The directory structure of a filesystem _is_ an index - an index of files. What's wrong with using an index as an index? > >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. Um. My understanding of EA's, as being discussed, is something like an inode list, eg, each 'fork' has its own inode, but only one 'root' inode appears in the filesystem. Or put another way, since we aren't imposing a limit on the number of EA's, and we can't have an infinitely sized inode, there has to be some kind of extension mechanism. Now, the only 'atomicity' is provided by disk blocks. As soon as we start using these "extended" inodes, meaning they are scattered across the disk, that 'atomicity' is gone. lost+found only comes into play when the filesystem is damaged. What is to prevent a 'sub-node' from getting lost? -- Jonathan