Date: Sun, 27 Oct 1996 23:59:42 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> Cc: julian@whistle.com, hackers@freebsd.org Subject: Re: DEVFS problem Message-ID: <287.846457182@critter.tfs.com> In-Reply-To: Your message of "Sun, 27 Oct 1996 23:17:45 %2B0100." <166.846454665@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I compiled DEVFS with debugging, and the output looks like this: [...] vntodn vntodn write read vntodn read vntodn reclaim vntodn reclaim vntodn read vntodn vntodn write read vntodn reclaim vntodn reclaim vntodn read vntodn vntodn write read vntodn read vntodn reclaim vntodn reclaim vntodn read vntodn vntodn write read vntodn read vntodn reclaim vntodn reclaim vntodn read vntodn [hang] If I have understood things right, DEVFS has no vnodes that need cleaning as often as that, and I generally belive that the refcount/ usecount on vnodes associated with DEVFS is bogus, right ? Wouldn't it be smarter to allocate the vnode when a DEVFS bdev node is created, and ref' it so we're sure it stays around ? That way all the block-dev alias crap can be done by pointing the DEVFS nodes at the same (& correct) vnode. Of course we tie up a number of vnodes that way, but since most bdev's tend to be used, with the exception of slices that are not mounted, I think that is a very small loss, compared to the mess the alias code really is. This would also mean that if a driver adds two bdev names for the same dev_t, they will effectively become hardlinks to the same "inode" rather than two separate "inodes", which I think is more correct behaviour when we're talking about block devices anyway. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?287.846457182>