[Top][All Lists]

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

Re: [] zisofs test looks unsuitable

From: Thomas Schmitt
Subject: Re: [] zisofs test looks unsuitable
Date: Fri, 27 Aug 2021 00:14:20 +0200


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 ?

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

> 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.
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.

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

Have a nice day :)


reply via email to

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