Glenn McGrath wrote:
The comparisons to cramfs does favour squashfs for lowmem installs.
My only reservation is the fact that its not in the official kernel, but
it sounds like you intend to stick it out and maintain it outside the
offical tree, so that shouldnt be too much of a problem.
Yes. I
The comparisons to cramfs does favour squashfs for lowmem installs.
My only reservation is the fact that its not in the official kernel, but
it sounds like you intend to stick it out and maintain it outside the
offical tree, so that shouldnt be too much of a problem.
Glenn
--
To UNSUBSCR
Drew Scott Daniels wrote:
The order of the files in the initrd file can make a difference if the run
length or context of the compressor can span multiple files (large block
sizes). I don't know how one could change the order of files in an initrd
file, but I suspect it's like tar, just pass them
On Thu Feb 20, 2003 at 12:39:14PM -0600, Drew Scott Daniels wrote:
> It's interesting to note that in this case -8 and -9 yield the same
> results, but -9 requires more memory at the time of decompression and
> compression. I suspect the memory usage statistics will remain constant
> for any file (
From: ftp://sources.redhat.com/pub/bzip2/docs/manual_2.html#SEC7
Compress Decompress Decompress Corpus
Flag usage usage -s usage Size
-1 1200k 500k 350k 914704
-2 2000k 900k 600k 877703
-3 2800
On Wed, 19 Feb 2003, Glenn McGrath wrote:
> On Tue, 18 Feb 2003 10:08:45 -0600 (CST)
> Drew Scott Daniels <[EMAIL PROTECTED]> wrote:
>
> > Would squashfs work? I doubt this is an optimal compression, but it
> > might be better than alternatives. Currently the best free solution
> > might be based
Glenn McGrath wrote:
Im not confident about squashfs, i think the best solution is
initrd.romfs.gz for normal installs, but squashfs or cramfs might be
good for lowmem installs, i havent looked into squashfs yet, not sure
when i will get time.
Hi,
I'm pleased that people (thank you Drew) are
On Wed Feb 19, 2003 at 05:16:48PM +1100, Glenn McGrath wrote:
> On Tue, 18 Feb 2003 10:08:45 -0600 (CST)
> Drew Scott Daniels <[EMAIL PROTECTED]> wrote:
>
> > Would squashfs work? I doubt this is an optimal compression, but it
> > might be better than alternatives. Currently the best free solution
On Tue, 18 Feb 2003 10:08:45 -0600 (CST)
Drew Scott Daniels <[EMAIL PROTECTED]> wrote:
> Would squashfs work? I doubt this is an optimal compression, but it
> might be better than alternatives. Currently the best free solution
> might be based on PPMd which has been packaged into Debian.
>
Im no
On Wed, 5 Feb 2003 14:08:14 +1100 Glenn McGrath wrote:
> On Tue, 4 Feb 2003 10:27:59 -0600 (CST) Drew Scott Daniels
> <[EMAIL PROTECTED]> wrote:
>
>> It looks stable enough now, but I wonder why it hasn't been included
>> in the Linux kernel (even 2.5?). I also have to question the value of
>> zlib
On Fri, Feb 07, 2003 at 01:17:58AM +, Kenneth MacDonald wrote:
> Glenn> The reason gzip compression is used on intrd's is becasue
> Glenn> the kernel and some bootloaders (grub at least) support it.
>
> Glenn> It would be great is we could use better compression on the
> Glenn
> "Glenn" == Glenn McGrath <[EMAIL PROTECTED]> writes:
Glenn> On Tue, 4 Feb 2003 10:27:59 -0600 (CST)
Glenn> Drew Scott Daniels <[EMAIL PROTECTED]> wrote:
>> It looks stable enough now, but I wonder why it hasn't been
>> included in the Linux kernel (even 2.5?). I also have to
On Tue, 4 Feb 2003 10:27:59 -0600 (CST)
Drew Scott Daniels <[EMAIL PROTECTED]> wrote:
> It looks stable enough now, but I wonder why it hasn't been included
> in the Linux kernel (even 2.5?). I also have to question the value of
> zlib compression vs other types of compression, but then I suppose
I've been meaning to file an RFP on squashfs for a while, and I finally
got around to it ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=179672
). While I was at it, I figured I might ask if this filesystem has been
looked at for use in any debian media. I know there has recently been some
compa
14 matches
Mail list logo
