lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 20 Dec 2010 06:17:30 +0000
From:	Phillip Lougher <phillip@...gher.demon.co.uk>
To:	Bruno Wolff III <bruno@...ff.to>,
	Lasse Collin <lasse.collin@...aani.org>
CC:	Linux Kernel Development <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] Squashfs: add XZ compression support

Bruno Wolff III wrote:
> On Thu, Dec 09, 2010 at 06:05:55 +0000,
>   Phillip Lougher <phillip@...gher.demon.co.uk> wrote:
>> XZ support has (obviously) also been added to the squashfs tools (Mksquashfs
>> & Unsquashfs).  These changes are available from the Squashfs CVS repository
>> (http://sourceforge.net/projects/squashfs/develop).
> 
> Do you have an estimate for when you will make a release with these changes
> and what will likely be the version number? I want to see if it makes sense
> to start tracking the development version for F15 or F16 and what to use
> for the version.
>

Hmm, I don't know when F15 or F16 is destined to appear! (I guess roughly
3 to 6 months minimum time but correct me if I'm wrong).

Lasse collin's comment re: dictionary sizes threw a spanner in the works
so to speak as I realised my current patches don't allow users to specify
the dictionary size, which appears rather useful judging by Lasse's
comments that a dictionary size of 50% of block size only impacts
compression by 1%.  This makes it rather obvious that allowing users to
specify dictionary size in addition to block size is extremely desirable.

The rather unfortunate issue is that the current Squashfs file format
doesn't allow compressor specific options to be stored, for example it
allows compression type (i.e. gzip, lzma, lzo etc) to be stored, but there
is nowhere to store a dictionary size.

So, this has led to a week of thinking about how to add compressor
specific options to the Squashfs file format which is 100% compatible with
pre-existing 4.0 file systems and file system code.  I have settled on an
extension which is 100% compatible and which fits in well with the file
format (i.e. it is not a hack).

What does this mean in relation to your questions?  Well basically it means
in a week's time or before I'll be in a position to respin the kernel
patches to include compressor specific options support (i.e. dictionary size),
and there will be the corresponding CVS changes for the Squashfs tools.

As far as I'm concerned this makes a good point to make a new Squashfs tools
release (very few people trust the CVS versions in my experience and always
go for the last released version).  I'll probably wait for a couple of weeks
just in case CVS downloaders find any bugs (in practice I hardly ever get any
bug reports from the CVS version).  This means a Squashfs tools 4.2
release mid January.   How does this fit in with the release schedules for
F15 and F16?

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

Powered by blists - more mailing lists