--XOIedfhf+7KOe/yw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 g=
oes
> > > inactive and can be safely put to rest.
> >=20
> > 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=
=20
> > kernel to crash.
>=20
> 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=
=20
a deadfs operation vector (and routines, maybe) for devices, and use it=20
when we deaden a device.

"deadfs" means your file system is dead. We don't necessarily ned it to=20
mean that your vnode is dead. And for devices which are mounted, chances=20
are we don't want that meaning. :-)

The one thing I see that might be tricky is to make things work right w/=20
revoke(2). If you revoke something, you need a dead device vnode that does=
=20
nothing. If however we unmount /dev, you want a deadfs device vnode that=20
still does i/o. Character devices always want a dead node, but we need=20
some differentiation between "dead" and "orphaned" block devices.

Take care,

Bill

--XOIedfhf+7KOe/yw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFHl7CXWz+3JHUci9cRApIqAJ9seV/tcbf9TRlLgMeCFTJUxxcDDwCeMsQ0
AhjVmGF5DFgwI81fLPhoyac=
=O6XP
-----END PGP SIGNATURE-----

--XOIedfhf+7KOe/yw--