[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
The following reply was made to PR bin/20767; it has been noted by GNATS.
From: Jukka Ruohonen <jukka.ruohonen%iki.fi@localhost>
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.]
Main Index |
Thread Index |