Date: Thu, 17 Jul 2003 19:10:18 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: David Schultz <das@FreeBSD.org> Cc: John De Boskey <jwd@bsdwins.com> Subject: Re: swap partition > 4G Message-ID: <8011.1058461818@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 14 Jul 2003 10:00:24 PDT." <20030714170024.GA27936@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >I think >it would be even cooler if a more general and complementary >interface to ccd(4) were developed that provided a generic way of >allocating and deallocating virtually-addressed disk blocks from a >pool of storage, but I don't have the code for it. :-P It's called FFS, and we don't want it for swap, in particular we want something which does not need a lot of RAM _or_ disk reads to figure out which bits are busy and which are not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8011.1058461818>