Date: Thu, 17 Jul 2003 11:18:28 -0700 From: David Schultz <das@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: John De Boskey <jwd@bsdwins.com> Subject: Re: swap partition > 4G Message-ID: <20030717181828.GA48738@HAL9000.homeunix.com> In-Reply-To: <8011.1058461818@critter.freebsd.dk> References: <20030714170024.GA27936@HAL9000.homeunix.com> <8011.1058461818@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 17, 2003, Poul-Henning Kamp wrote: > In message <20030714170024.GA27936@HAL9000.homeunix.com>, David Schultz writes: > > >As far as moving the responsibility for striping swap to ccd(4) is > >concerned, that sounds like a step in the right direction. > >However, it's a completely orthogonal issue. > > Fully agreed. > > >The ~150 bogus lines > >of code that could be killed have nothing to do with the size > >limitation. Also note that ccd(4) can't fix all of the bogosity. > >For instance, you're still stuck with static striping, and you > >have to pretend that (MAXDEVS - curdevs) packs are full. > > First of all, there is little point in striping things the way it > is done today, it would probably be equally efficient, if not more > so (due to larger chunks being possible), to concatenate the swapon'ed > devices and allocate from the in a round-robin or even, now that > we have the statistics supporting such decisions, based on > disk-busyness. We will be able to do that with ccd(4)? Cool! Having a way to stripe based on disk business and add and remove space dynamically is basically what I was looking for. How would the interface work, though? I assumed you would just have the swap subsystem use one big virtual concatenated device, but that seems to limit ccd's ability to make any striping decisions dynamically, since ccd only understands read and write, not allocate and free.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030717181828.GA48738>