[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FWD: dh_compress



On Thu, Nov 04, 1999 at 11:14:35AM +0100, Massimo Dal Zotto wrote:
> > I understand the theoretical 4095 byte file, but if you changed it to 2k
> > there would be the theoretical 2047 byte file and the 1023 byte file ...
> > IMO it ain't broke, soo...
> 
> I don't agree.
> 
> The default ext2 blocksize is 1k and very few people change it. So most of
> the filesystems around use this minimum blocksize.

mkext2fs defaulted to 4K blocks on my drives, but then I have _BIG_
partitions.


> If the goal of dh_compress is to save space we should try to compress any
> file greater than the minimum blocksize. If we store a 4k file compressed
> to 1k on a default 1k-block filesystem we can save 3k while if we store
> the same compressed file in a 4k-block filesystem we don't save any space
> but we also don't lose anything, except maybe a very small delay needed for
> decompressing the file, but this should be unnoticeable for a small file.

Understandable, I just don't think the savings is that significant, even
on a 1K block filesystem.  If you can show me an average system or two's
differences in filesize I might be more encouraged to agree with you, I
just don't think there are enough cases to be worth changing the current
game plan.


> I propose therefore that the the minimum size candidate for compression is
> the minimum filesystem blocksize + 1 byte.
> 
> I can agree that the total space saved by compressing all those small files
> can't be very much, maybe 50-100k, but is a question of principle. If we
> want to save disk space let's save all the possible space.

I can't reasonably believe you'll get even 50k on a system that's already
strapped for diskspace.  Plus I think we should consider the AVERAGE
system (where I rate average as a low end Pentium which can be had for
next to nothing) for the general case.  There are ext2 disk compression
drivers which do a much better job of what you describe using the same
technologies--transparently.


> I would personally like that also the copyright files would be compressed.
> I don't think that the compression changes the copyright itself or the
> licencing policy of the package, or the ability of the user to read this
> information. We must install anyway the package in a debian system to be
> able to read the docs and zless is already installed in every base system.

I think Copyrights should NEVER be compressed for the sole reason that we
need to make them as visible as possible without shoving them down
people's throats.  I realize the triviality in typing an extra z before
the less, however I'd more rather never hear the argument that we're at
all obscuring Copyright information.

-- 
- Joseph Carter         GnuPG public key:   1024D/DCF9DAB3, 2048g/3F9C2A43
- knghtbrd@debian.org   20F6 2261 F185 7A3E 79FC  44F9 8FF7 D7A3 DCF9 DAB3
--------------------------------------------------------------------------
<Apple_IIe> anyone seen my 80 column card?

Attachment: pgpEhsIEGSKuE.pgp
Description: PGP signature


Reply to: