Date: Mon, 29 Apr 1996 18:59:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: julian@ref.tfs.com (JULIAN Elischer) Cc: terry@lambert.org, hackers@FreeBSD.org Subject: Re: devfs policy question. Message-ID: <199604300159.SAA06115@phaeton.artisoft.com> In-Reply-To: <199604300011.RAA04376@ref.tfs.com> from "JULIAN Elischer" at Apr 29, 96 05:11:16 pm
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". > > The driver wants to delete it because it has been physically removed.... But the FS wants to write it because the image on the removed media is inconsistent and the media won't contain the data you think it cintains on the next mount. So the devfs wants to refuse the delete with "EBUSY", and that wants to generate a console message, like: "PLEASE REINSTALL VOLUME 'foo' NOW, IT WAS NOT PROPERLY UNMOUNTED! IF YOU DO NOT INSTALL VOLUME 'foo' NOW, IT'S CONTENTS MAY BE DAMAGED!" On the console (or better, a syslog popup requester). > > This is a "device departure event"... I assume this is for removable > > media of some kind? > > possibly.. (or a repartitionning) Ah yes. Incidently, this is one place where Windows 95 loses its mind. 8-). In theory, repartitioning should not be allowed out from under mounted devices. > > > 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. > > define 'pending'.. and what if the device has already departed.. > (e.g. PCMCIA-card been ejected).. Then you scream "I WANT THAT THING BACK, IT'S MINE!". 8-). > > > 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 *only* 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. > > Which I would consider correct if the device was removed.. No, the reference instances should "lock" it. Just like you can't unmount cleanly unless the file are all closed. The problem comes in on the clean cycle, which has been delayed until after the eject because of the current scheme. You end up with dirty, unreferenced buffers in cache with no way to force them out. 8-(. > > > 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.). > > why would this require commiting to stable storage? Because pipe data buffers are FS data buffers, and you don't have FS data bufffers without an underlying FS. Unless you merge MFS into devfs, it means stable storage (or MFS "translucent" mounting or some similar FS overlay). 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?199604300159.SAA06115>