Date: Mon, 29 Apr 1996 15:32:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: julian@ref.tfs.com (Julian Elischer) Cc: hackers@FreeBSD.org Subject: Re: devfs policy question. Message-ID: <199604292232.PAA05343@phaeton.artisoft.com> In-Reply-To: <199604261858.LAA27576@ref.tfs.com> from "Julian Elischer" at Apr 26, 96 11:58:42 am
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... Keep in mind, these represent my opinions, not necessarily
those of the FreeBSD core team ... ]
> What should devfs do to a device that is open when
> the driver requests that it be deleted?
Refuse the delete with "EBUSY".
> what should happen to the vnode for /devfs/rsd1s1d if the slice code
> decides that that device makes no sense any more, but there is a reference
> because a preocess somewhere has it open.. (what if it's mounted?)?
This is a "device departure event"... I assume this is for removable
media of some kind?
For devices with lockable eject, the eject should be locked while the
device is mounted.
For devices with lockable eject whose "eject" button functions as an
"eject request" when the device is locked, the "eject request" should
be interpreted by the mount code as "flush pending device departure;
disallow subsequent requests".
> At the moment a vgone() is done on the vnode.
> is this right?
No, it's bogus as all get-out. Pending writes really screw up.
This wants more comprehensive/consistent device management code.
> It is dissociated from devfs and vgone (well vclean actually)
> associates it with the deadfs vnops.
>
> Is this the right thing to do?
No, this is bogus as well, and had to do with there 8only* being a
vnode/extent mapping on buffer cache pages, such that valid cache
pages without an associated vnode are discared and reloaded instead
of getting a cache hit. This is most obvious in the vclean/VOP_LOCK
code for vnode locking, and the UFS ihash cache, which operates as a
"second chance cache" for discarded vnodes fending LRU flush by
vclean. This is the true source of the "free vnode isn't" panic.
> ---------------
>
> Policy question number two
> should devfs allow the creation of fifo/named pipes?
> I tend to think yes.... they are dynamic and kinda-like devices
>
> ---------------
I think no (you must be thinking of syslog?). This would require
committing devfs to stable storage, which in turn would mean we could
not murder specfs (which needs to be murdered).
IMO, devfs should be non-optional (ie: no specfs, no commit to stable
storage, kernel mount before "/", etc.).
> Policy question number three
> When returning a vnode from devfs_lookup() an attempt is made to see
> if that node already has a vnode associated with it, and if it is
> not in use, it adds a reference and resurects it. This means that
> if you have 100 devices, there are 100 vnodes sitting around
> waiting to be reused. Very few of these would be actually re-used
> for devices..
>
> Should the devfs try re-use the same vnode (or a small pool of vnodes)
> again and again for different devices, to avoid thrashing the vnode
> cache? If so, does anyone have any ideas about how it can know that
> the vnode that i just gave away with a lookup() is no-longer
> referenced and can be re-used straight away? (rather than going
> asking for another... Devfs vnodes want to be put at the end of
> the LRU Queue, as they can be recreated very quickly (unless there
> are aliases).
LRU insertion order is an issue for cache thrashing in general; IMO,
there needs to be an insertion policy mechanism and a link mechanism
for per-vnode LRU'ing to implement per vnode working set restrictions
to avoid cache thrashing (potentially modified via madvise).
I think the current allocation method for vnodes is critically
bogus; it's also a (potentially necessary in some cases) artifact
of FS stacking. Really, the vnode structures want to be allocated
from a pool created on a per mount instance basis in an FS. For
FFS, this means they are malloced as part of the mount internal
to the in core inode structure for the FFS inodes. For devfs, this
means that they would be preallocated (or demand-allocated for
clone devices) in the exported device descriptor.
This implies a fundamental change in the system open file table
mechanism to add reference counts and guarantee uniqueness -- this
is something sfork and kernel threads both want anyway.
If the vnodes don't compete on a system-wide basis, then they
don't have an issue with LRU contention.
The missing piece is that a VFS_VNFREE (vfsop for freeing vnodes)
would need to be defined -- as in SunOS, Solaris, and SVR4 -- and
used in place of the generic free (or as a calldown from it).
This doesn't prevent an FS implementation from internally
seperating vnodes from in core versions of on disk inodes (such as
might be desirable to maintain hard links with real parent pointers
in a FS for things like inherited rights and trustee information --
you inherit one set of rights from one access path, another from
another, and the access path dictates which re in effect for your
reference instance. Which is what the vnode *really* is...).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604292232.PAA05343>