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 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -------------------------------------------------------------------------- <Apple_IIe> anyone seen my 80 column card?
pgpxOOLphMgRu.pgp
Description: PGP signature