Re: [isocompr PATCH]: first comparison with HPA's zisofs

H. Peter Anvin (hpa@zytor.com)
Sun, 17 Jun 2001 10:03:10 -0700


Roberto Di Cosmo wrote:

>
>
> I have only the following (minor) criticisms
>
> - the transparent compression scheme does not rely on a special
> filename extension (it was .gZ in isocompr): a file foo gets
> compressed to a file foo, and the only way to see if foo is
> compressed or not is to read the header. This has pros and cons...
> and I wonder what the reasons of this choice are.
>

It caused ALL kinds of nastiness; the chosen solution was vastly simpler
on a whole bunch of axes.

> - the tools allow to compress/decompress only a whole directory tree,
> while it should be possible to act on a single file also: in DemoLinux
> not all files are compressed (some must be readable under (hem...) other
> less interesting OSs for example ;-)) and the distinction is not on
> a per-directory basis.
> [easy to fix, see patch at the end of this message: I did this to
> be able to try zisofs with DemoLinux]
>

You can do this by having the compressed and uncompressed files in
different directory trees and merge them using mkisofs. I personally
think that's a cleaner solution, even if your suggestion might make
sense anyway. Your patch, though, is too ugly to live.

> - it seems to me that this was written with 2.4.x in mind, and I did not
> find a version for 2.2.x kernels :-(
>
> Now I wonder, if zisofs is going to be included into 2.5 (I would strongly
> vote in favour!), would it be worthwhile to include a compatibility mode
> to read the isocompr blocksized format too?
>

No. isocompr was misdesigned, and such a compatibility mode would
needlessly complicate everything.

-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/