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

Internet Message Format | 1992-08-14 | 3.6 KB

Xref: sparky comp.unix.programmer:4309 comp.unix.internals:1693 comp.sys.hp:9307
Path: sparky!uunet!dtix!darwin.sura.net!mips!sdd.hp.com!caen!hellgate.utah.edu!fcom.cc.utah.edu!gateway.univel.com!ns.Novell.COM!gateway.novell.com!ithaca.Eng.Sandy.Novell.COM!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: 14 Aug 92 22:35:05 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (NetNews)
Organization: Novell NPD -- Sandy, UT
Lines: 56
Nntp-Posting-Host: ithaca.eng.sandy.novell.com

In article <[e-mail]> [e-mail] (Jim Reid) writes:
>In article <[e-mail]> [e-mail] (Marcus Leech) writes:
>
>   Granted there isn't always a 1 to 1 relationship between a files internal
>     "handle", and its name.  In the real world, programs refer to files by
>     name, and in the real world, system managers frequently need this
>     information either to debug some system process, or because they want to
>     take a disk offline, and they need to know which processes have *which*
>     files open on the disk.  You can avoid having to do the reverse mapping
>     simply by storing the name information in such a way as to be generally
>     useful, and not cost very much.
>
>Hmmm. On some machine there could be thousands of active files. Having
>the kernel maintain a list of those filenames might cost more than you
>think. [If it's a choice between assigning 100K of kernel memory to
>I/O buffers or process page tables or a list of active filenames, I
>wouldn't choose the list of filenames.]
>
>What would such a scheme do in the case of a process which unlinks an
>open file?

*Very* good point against keeping the data in the kernel.  There is also
the worse case of a file having been moved.  Not only is there not a file
where the kernel says it is, theres a file open that the kernel knows
is open but can't know it's new name.

If we return to the question of taking a device offline, I have to argue
that it is irrelevant whether or not you know the name of the file; you
only need to know the name of the processes which have files open on the
device; you could care less what the names of the files are.  Killing
the processes will kill the references.  You don't really care what *files*
are referenced ... you care what *devices* are referenced.

By traversing all active process structs in the kernel, one can get the u
structs for each process, and thus the pointer to the locked vnodes for that
process (this will be in the per process fd table and in the current working
directory pointer).  It's easy to find out what device or file system a
vnode is open to.  From this, you determine if you want to kill a particular
process that's holding your FS open.

Alternatively, most file systems support forcible unmount; you should
probably wall to tell your users to logout/kill their program/change to
a safe directory so as to give them fair warning that you may destroy one
or more of their files.  This is probably inferior to killing off the
processes and umounting, and killing again if that fails, repeating until
the thing unmounts, but it will certainly take less code (ie: no code)
in enough cases that it will be worthwhile.


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

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