[Top][All Lists]

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

Re: [] zisofs test looks unsuitable

From: Glenn Washburn
Subject: Re: [] zisofs test looks unsuitable
Date: Thu, 26 Aug 2021 22:30:30 -0500

On Fri, 27 Aug 2021 00:14:20 +0200
"Thomas Schmitt" <> wrote:

> Hi.
> Glenn Washburn wrote:
> > I think the changes to get the test
> > working are worthy of inclusion so that the tests are ready when
> > this feature gets implemented.
> Do you think my draft of a commit message is ok ?

Seems good to me.

> Probably i should mention that this test will fail until zisofs is
> implemented.

Yes, but as I noted before, the ziso9660 is not actually run by any
"make check" tests, which makes sense if its not actually implemented.
Also the ziso9660 fs test fails currently anyway, so I don't see a
problem here.

> > I'm not familiar with that code nor the
> > format details, but it sounds like you might be able to determine if
> > its something somewhat easy to add to GRUB.
> Well, i wrote an implementation as libisofs filter (which differs much
> from a filesystem driver) and a documentation of the format:
> (Since noon our project web server is down. I need to pester the web
> master to check which useless piece of software crashed it this time.)
> Implementing SUSP entry "ZF" would be a substantial change to
> grub-core/fs/iso9660.c including a new dependency on zlib.

There wouldn't be a new dependency on zlib. Grub already supports zlib
decompression using grub_zlib_decompress in grub-core/io/gzio.c. I
suspect this would work fine.

> The adventure would probably begin at function susp_iterate_dir()
> which interprets some Rock Ridge SUSP entries.
> Then i'd need to know which functions tell the file size and do the
> reading of file content data and how to make the info from the ZF
> entry known to them.

Functions for dealing with files can be found in include/grub/file.h
and grub-core/kern/file.c

> The Linux kernel has an implementation from the inventor, H.Peter
> Anvin. (With a bug for machines with PAGE_SIZE > 32 KB
> and a dire need for a readahead implementation.)
> And there is the successor format zisofs2, not yet in the kernel
> (Thanks to all the sites which store what i write.)
> Last november a zisofs2 patch of ~200 lines enabled the then actual
> 5.10.0 release candidate to read the new format. But nearly a year of
> bitrot already devalued my readahead patch. So my local test kernel
> is the only one in the world which can read giant zisofs2 compressed
> files at high speed.

I'm sure support for the new format would be welcome as well and it
sounds like you're well-positioned to make that happen.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]