Date: Fri, 10 Feb 95 14:57:59 MST From: terry@cs.weber.edu (Terry Lambert) To: tinguely@plains.nodak.edu (Mark Tinguely) Cc: peter@bonkers.taronga.com, davidg@Root.COM, hackers@FreeBSD.org, jmb@kryten.atinc.com Subject: Re: MIT SHM X11 extensions? (fwd) Message-ID: <9502102158.AA13007@cs.weber.edu> In-Reply-To: <199502101804.AA23116@plains.NoDak.edu> from "Mark Tinguely" at Feb 10, 95 12:04:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> because no one has taken the time to fix it right. I agree it should go. > > > What else would you do if you opened a currently running executable for > > writing? [ ... force to swap vs. vnode reference and inode replacement in the directory to keep the image on the file system itself ... ] > (of course the filesystem switch-a-roo response to the problem has > difficulties when (time sequence): > open execute > open write (save old file -- any new executes will use this) > close write > open execute (should use new executable) > open write (backup vnode pointer being used what now? make the backup > vnode pointer an array?) > ... My answer to using this mechanism is to make the exection reference instance the equivalent of an open reference -- that is, you can't get a vnode above the VFS layer without a VN_HOLD, and only on a VN_RELE of a vnode with a reference count decrement to 0 causes the inode to go free. The problem with using the vnode instead of swap in this case is the fact that since NFS is stateless, if the executable is loaded from the NFS server, the file instance will be destroyed on delete because there is no open state VN_HOLD, nor is thate a distinction between open for run and open for other read necessary to implement vnode pointer backup. There is also the fact that the act of the vnode backup itself must occur fully at open-for-write time, since you must have unreferenced but potential pages available. This is functionally equivalent to a kernel precopy to an inode without a directory entry prior to actually modifying the directory entry itself. In point of fact, one could swap the open reference on the node instead of the actual directory entry after such a copy -- this would make it overall less complicated, but would add the problem of reverse looking up the vnode for other execution instances. Basically, a linear traversal of the system open file table, which isn't really too bad. No approach other than the copy-to-swap resolves the two NFS problems satisfactorily -- that of the image being altered while being run on a machine other than the machine doing the altering, and that of the image becoming unavalable as a swap source in the case that the server goes down (anyone who has uses a dataless SunOS has seen this one). > we talked about this before on the net. the one consideration is should > all executables be in swap, so that we can restart the apps where we stopped > (notebook memory saver philosophy). or very least all NFS on swap because > they are too dump to figure about writes. Yeah; I think the "pick up where you powered off" capability would have a high cool factor. 8-). Terry Lambert terry@cs.weber.edu --- 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?9502102158.AA13007>