Re: bin/20767

[Jukka Ruohonen <jukka.ruohonen%iki.fi@localhost>]

The following reply was made to PR bin/20767; it has been noted by GNATS.

From: Jukka Ruohonen <jukka.ruohonen%iki.fi@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/20767
Date: Wed, 14 Oct 2009 14:26:37 +0300

 On Wed, Oct 14, 2009 at 05:15:04AM +0000, Robert Elz wrote:
 >    |         - The patch uses kvm(3).
 >  
 >  where I suspect that adding yet more kmem grovellers, where the
 >  direction has been (for good reason) to eliminate them, is not going
 >  to meet with much success.
 
 Fair enough. Reducing the use of kmem sounds highly welcome, but I didn't
 know that the usage of kvm is discouraged also in this particular scenario.
 
 >  If this data needs to be made available at all the right way to do it
 >  (IMO) is to have cgdconfig manage it - just keep a record of what is
 >  created and destroyed in a file somewhere (use file locking to avoid
 >  race conditions with multiple instances of cgdconfig running in parallel,
 >  which isn't likely, but ...).    I'd stick it in /var/run so it gets
 >  cleaned automatically on reboot.
 
 If this route is taken, it would perhaps be a good idea to have a common API
 that all related tools (ccdconfig, vnconfig, etc.) could possibly use.
 
 >  Or, have cgdconfig write the device name into somewhere in the header
 >  of the mounted device, then all you need is to be able to iterate over
 >  possible /dev/cgdN's and find which ones are configured (I suspect methods
 >  do do that already exist) and upon finding a configured one, extract
 >  the name from its data.
 
 How about the use of cgd for swap devices, for an instance?
 
 >  [Aside: I'm not sure the data is really needed ... I use cgd, and I've never
 >  encountered the need - on the other hand, if cgd could be made a cloneable
 >  type device, so I don't need to pick the N in /dev/cgdN but it can be
 >  picked for me, that would be great.]
 
 Agreed.