Date: Fri, 20 Jul 2001 11:04:50 +0300 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Andrew Hannam <andrew.hannam@bigfoot.com> Cc: small@FreeBSD.org Subject: Re: Extending md(4) to allow it use pre-compressed disk image Message-ID: <3B57E622.5EA768C4@FreeBSD.org> References: <3B52CC08.1B08210F@FreeBSD.org> <009901c11045$d0536a40$0104010a@famzon.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Hannam wrote: > Does this include the necessary utilities to enable it to be written into > the kernel so that the (bloated) loader is not needed in a Pico situation ? I suppose that it could be written into the kernel like any other md(4) image. The only problem in this sutuation is the fact that we need to tell md(4) driver somehow that the image is in fact compressed one, not just plain md(4) image. It is easier with loader(8), because it allows specifying type of the image (i.e. md_image vs md_image_compressed). > I would imagine that something like the "write_mfs_in_kernel" utility. You > may also need some pre-compression utility so that you know how much space > to allocate into the kernel image when building the kernel. The write_mfs_in_kernel utility should work w/o problems with compressed image, however it is necessary to create an image before compiling the kernel to estimate size that needs to be allocated. -Maxim > ----- Original Message ----- > From: "Maxim Sobolev" <sobomax@freebsd.org> > To: <small@freebsd.org> > Cc: <arch@freebsd.org> > Sent: Monday, July 16, 2001 9:12 PM > Subject: Extending md(4) to allow it use pre-compressed disk image > > > Hi folks, > > > > I extended md(4) driver to allow it use pre-compressed disk image. In > > contrast with the current implementation, when loader(8) on loading > > decompresses compressed image and holds it uncompressed in the memory, > > with new feature loader(8) places compressed image into a memory, > > while md(4) decompresses sectors when they are read. This could be > > useful to decrease minimal memory requrements on FreeBSD install or in > > another cases when memory is scarce. Performance is quite good - even > > P133 reads data from such device at 2-2.5MB/s. > > > > Since standard gzip format is not really suitable for the task I > > created an utility that splits original image into clusters (cluster > > size could vary), compresses each cluster using zlib and writes > > compressed clusters along with information about offset of each > > cluster into resulting image. After that compressed image could be put > > into the floppy or other media, loaded using loader(8) and accessed > > through md(4) as usually. The only difference is that it is impossible > > to write into resulting disk. > > > > I would like to know if there is enough interest in integrating this > > feature into base system, please let me know what do you think about > > it. > > > > -Maxim > > P.S. Please keep me on the CC list. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-small" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B57E622.5EA768C4>