Date: Wed, 18 Jul 2001 10:45:35 +1000 (EST) From: Iain Templeton <iain@research.canon.com.au> To: small@FreeBSD.org Cc: arch@freebsd.org Subject: Re: Extending md(4) to allow it use pre-compressed disk image Message-ID: <Pine.LNX.4.10.10107181032510.21394-100000@blow.research.canon.com.au> In-Reply-To: <200107180000.f6I00pk01057@mail.uic-in.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Jul 2001, Maxim Sobolev wrote: > Original size of the image: 10485760 bytes > Size of the image when compressed with gzip -9: 3855949 bytes > > Cluster Size of Compressed Overhead Compared Amount ofRAM > Size Image to gzip'ed Image Saved > ------- ------------------ ----------------- ------------ > 512 5,932,330 54% 4,553,430 > 1024 5,246,779 36% 5,238,981 > 2048 4,792,210 24% 5,693,550 > 4096 4,482,894 16% 6,002,866 > 8192 4,258,122 10% 6,227,638 > 16384 4,111,334 7% 6,374,426 > 32768 4,004,817 4% 6,480,943 > 65536 3,939,52x 2% 6,546,233 > > Both the driver and compression utility support different block > sizes, so it is really up to user whether he preffers performance > over compression ratio or compression ratio over performance. > Obviously that with the larger block sizes the driver will do > more and more redundant work because to read some, arbitrary small > portion of the cluster the driver has to decompress the whole > cluster. However, provided simple MRU cahe effectively masks this > effect by holding dozen of the most recently used clusters in > decomressed form, so that from the performance standpoint difference > between the cluster size of 512 bytes and cluster size of 16KB is > ralatively small. > I know that the cramfs of linux used 4k blocks, but that was probably because they happened to be the page size of the machine we were using. This way when they needed to load a page, only one decompress was needed, and it was the entire resulting page. Would this provide any advantage to say the VM system? Our fs image was about 650k using initrd, and 900k using cramfs, but considering that it seemed to save about 1.5 MB of system memory, that wasn't a problem. It seemed that the initrd was in memory, but being loaded into memory again when the files were used... I guess it would be useful for us to be able to run a compressed filesystem out of flash memory, so only the used bits were in memory at a time. Actually, the bigger problem is that FreeBSD doesn't run on the MPC855/860, but that may change soon. Iain My 0.022c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10107181032510.21394-100000>