On Wed, Jan 23, 2008 at 10:55:13PM +0200, Antti Kantee wrote: > On Wed Jan 23 2008 at 12:49:09 -0800, Bill Stouder-Studenmund wrote: > > > This is the problem of forcibly unmounting a file system with device > > > vnodes on it. There was a small discussion about splitting specfs > > > into two layers: one for the "host" file system (tmpfs in this case) > > > and one for the actual device info (specfs). Then you could rip the > > > "host" part out without affecting the device part before the device goes > > > inactive and can be safely put to rest. > > > > I'd actually say this is a bug in deadfs or tmpfs. Since we know the > > vnode's still in use, we should leave one around that doesn't cause the > > kernel to crash. > > We don't make device vnodes deadfs so that they would still work. And I I think then we should. :-) > don't think teaching every file system to operate without its backing data > structures is very feasible. Hence, split it into two pieces so we don't > have to worry about it: the "frontend" (.e.g tmpfs) is deadfs'd while the > "backend" (specfs) continues operation until refcount drops to 0. Haven't we already done that split w/ specfs now? All we need to do is add a deadfs operation vector (and routines, maybe) for devices, and use it when we deaden a device. "deadfs" means your file system is dead. We don't necessarily ned it to mean that your vnode is dead. And for devices which are mounted, chances are we don't want that meaning. :-) The one thing I see that might be tricky is to make things work right w/ revoke(2). If you revoke something, you need a dead device vnode that does nothing. If however we unmount /dev, you want a deadfs device vnode that still does i/o. Character devices always want a dead node, but we need some differentiation between "dead" and "orphaned" block devices. Take care, Bill
Attachment:
pgpa_KUP71Sg9.pgp
Description: PGP signature