NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/unix/programm/4258

Internet Message Format | 1992-08-12 | 2.9 KB

Xref: sparky comp.unix.programmer:4258 comp.unix.internals:1682 comp.sys.hp:9210
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!mips!swrinde!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!gateway.univel.com!gateway.novell.com!thisbe!terry
From: [e-mail] (Terry Lambert)
Newsgroups: comp.unix.programmer,comp.unix.internals,comp.sys.hp
Subject: Re: inode to filename
Message-ID: <[e-mail]>
Date: 12 Aug 92 18:17:07 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: terry@thisbe (Terry Lambert)
Organization: Novell NPD -- Sandy, UT
Lines: 46
Nntp-Posting-Host: thisbe.eng.sandy.novell.com

In article <[e-mail]>, [e-mail] (Marcus Leech) writes:
|> In article <[e-mail]>, [e-mail] (Alan Barclay) writes:
|> |> I don't see it as a weakness, if there was a one to one relationship
|> |>
|> |>  [MS-DOS references delated].
|> |> I don't see the need to refer to a file from a inode number anyway,
|> |> the most common you can get a inode number is though stat or fstat,
|> |> and presumably you knew the filename in the past.
|> A common reason for wanting to do this is to determine what's going on in
|>   your system.  Which processes have which files open, etc.  This *is*
|>   useful, and UNIX has traditionally (and continues to be) weak in the areas
|>   of effective system management mechanisms.
|>
|> The traditional argument for not storing such information in the kernel
|>   has been "too much space".  Memory is now quite cheap, and with clever
|>   data structures, you don't pay that much for keeping filename<--->process
|>   mappings around.  If, for example, you recognize that there is a very
|>   high degree of shared name space, you can take advantage of that fact to
|>   dramatically reduce the storage requirements.
|>
|> In this *particular area*, VMS is better.

Then again, VMS is extent based, and uses a single allocation pointer.  This
means you not only serialize on the use of this pointer, multiple writers tend
to interleave extents, pretty much killing any benefits from extenting in the
first place.

VMS also has the ability to support hard links, which once again introduces the
parent/ancestor identification problem... which equivalent path to the file (and
which name for the file) did the user use when it was opened?

VMS also has a system-wide limit of 1024 channels, which aren't only used by the
file system.

VMS also does not have caching, per se.

The traditional argument for not storing the information in the kernel has been
reverse lookup overhead.

                    Terry Lambert
                    [e-mail]
                    [e-mail]

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.