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!harbinger.cc.monash.edu.au!news.bhp.com.au!mel.dit.csiro.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: <jlemonDpEw1v.4Ez@netcom.com> Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <4hptj4$cf4@cville-srv.wam.umd.edu> <4jerrj$f12@park.uvsc.edu> <jlemonDp1GFM.H4I@netcom.com> <4jpjb6$77c@park.uvsc.edu> Date: Fri, 5 Apr 1996 23:03:30 GMT Lines: 139 Sender: jlemon@netcom22.netcom.com Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20781 comp.unix.bsd.freebsd.misc:16759 In article <4jpjb6$77c@park.uvsc.edu>, Terry Lambert <terry@lambert.org> wrote: >jlemon@netcom.com (Jonathan Lemon) wrote: >] 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) > > >Bzzzzzzzzzzzzzzzzzzt.$home/bin > >% set path = ( $home/bin $path /usr/X11/bin) >% rehash >% /bin/ls $home/bin >foo ls >% /bin/ls $home/bin/foo >a.out icon eattr1 eattr2 >% /bin/ls $home/bin/ls >icon eattr1 >% ls >ls: Command not found % chmod +attributed_directory_bits $home/bin/foo % chmod +executable_directory_bits $home/bin/foo % chmod +attributed_directory_bits $home/bin/ls % rehash % ls foo ls % rm foo/a.out % foo % foo: executable not found. Yes, this breaks 'drop-through' shell hashing, in that if I had /usr/X11/bin/foo, it would not get run. So what? I don't think it's that big of a deal, and could probably be implemented either way. >> >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? > >A real index would be searchable in O(log2(n)+1) compares for >a total of n entries, whereas a directory used as an index >varies by implementation, and is never better than that, and >is more frequently simply O(n/2+1). I wasn't claiming that it was an efficient index, only that it _was_ one. Besides, O(n/2) is for a pure sequential search - if you have a multilevel directory, (eg: /u/j/jl/jlemon) you certainly get better than O(n/2). >] >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? > >The fact that it is not stored as a subnode in a correct >implementation. > >Specifically, if an entry is made in a directory, it is possible >for the imposition of heirarchy to lose tight binding with the >name space of the directory. > >It doesn't matter if this is a real directory, in the classical >sense, or an index directory in an inode entry. > >By restricting the allowable entry manipulations to not include >exposure in the FS namespace, the implementation can prevent it >from ever being possible to dissociated a fork from the node >that contains it. Uh. In an ideal world, maybe. But in an ideal world, lost+found would never be used, either. In another article of yours, I think that you mentioned something like "copying an EA file from one filesystem to another - either everything gets copied, or nothing.". Please tell me what happens when we pull the power switch in the middle of the copy. Does fsck just delete everything because it is an incomplete copy? If the disk block containing the "root" of the EA is damaged, does that mean I automatically lose _all_ of the files within that EA? >The failure mode in the directories is from the lack of a parent >pointer due to its exposure in the FS name space, specifically, >the way in which hard links are currently implemented. This sounds like you want to have a double-linked nodes (eg, the node knows about it's parent), which is currently not possible, as you pointed out, since with hard links, a file may have more than one "parent". Leaving this aside for the moment, wouldn't having double links increase the failure modes of the filesystem? >A fork is not a hard link, and if it is to not be limited by the >size of an on disk inode structure, it must not be associated >the same way inodes are associated with names. > >To think of it another way, DOS, OS/2, NetWare, and NTFS can not >lose file names because they are not directory entries, they are >attributes of the file. UNIX can, because logically names are >not attributes. Um, so I blow away the FAT table in DOS. I have not lost the filename, I have lost the _file_, "because the filename is an attribute of the file". Thanks but no thanks. -- Jonathan