Date: Sat, 21 Aug 1999 08:37:50 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Bruce Evans <bde@zeta.org.au> Cc: jb@cimlogic.com.au, atrens@nortelnetworks.com, current@FreeBSD.ORG, luigi@labinfo.iet.unipi.it Subject: Re: problem with vnconfig -s labels ... Message-ID: <11263.935217470@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 21 Aug 1999 16:30:57 %2B1000." <199908210630.QAA05678@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199908210630.QAA05678@godzilla.zeta.org.au>, Bruce Evans writes:
>>Hmmm, I know this is your code, but are you sure? 8-). My understanding of
>>dkmodslice() and friends is that they manipulate dev_t entries, but don't
>>actually initialise them. Since the subr_diskslice code takes a dev_t
>
>dkmodslice() once just manipulated bits in dev_t scalars. Now that dev_t
>is a pointer, dkmodslice() has to create something for the pointer to
>point to. That something needs to be fully initialised and not created
>more than once. The initialisation is apparently incomplete. Multiple
>creation is avoided by searching the list of previously created entries.
>
>Now I understand why my memory is filling up with unused dev_t
>entries :-). subr_diskslice churns through a not insignificant part
>of the per-drive minor number space (32 slices * 8 partitions * {raw,
>buffered}), using dkmodslice to create new dev_t's.
yes, this is the remaining sticky issue, and the only cure I know for
this and for the DEVFS issue is to relayer the slice/label processing
out of the device driver entirely. This is now almost possible to do.
--
Poul-Henning Kamp FreeBSD coreteam member
phk@FreeBSD.ORG "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11263.935217470>