linux-kernel - Re: [PATCH 0/3] Update LZ4 compressor module

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]

Message-ID: <20161223205320.GA30570@kroah.com>
Date:   Fri, 23 Dec 2016 21:53:20 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Sven Schmidt <4sschmid@...ormatik.uni-hamburg.de>
Cc:     akpm@...ux-foundation.org, bongkyu.kim@....com,
        sergey.senozhatsky@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Update LZ4 compressor module

On Thu, Dec 22, 2016 at 07:35:14PM +0100, Sven Schmidt wrote:
> On 12/22/2016 06:29 PM, Greg KH wrote:
> > On Tue, Dec 20, 2016 at 07:53:09PM +0100, Sven Schmidt wrote:
> >>
> >> This patchset is for updating the LZ4 compression module to a version based
> >> on LZ4 v1.7.2 allowing to use the fast compression algorithm aka LZ4 fast
> >> which provides an "acceleration" parameter as a tradeoff between
> >> compression ratio and compression speed.
> >
> > But why do this?
> >
> >> We will use LZ4 fast in order to support compression in lustre. LZ4 fast empowers
> >> us to do client-side as well as server-side compression/decompression while
> >> being able to provide appropriate parameters to enable users to tune lustre's
> >> behaviour to obtain the best performance/compression/etc. on their behalf
> >> (adapative compression).
> >
> > We don't care about lustre, especially as it is not merged into the main
> > portion of the kernel tree :)
> >
> > Seriously, work on fixing up the known issues in lustre before adding
> > additional features, I've only been saying this for a few _years_ now...
> >
> 
> Hey Greg and thanks for your time. Actually, we're not the guys behind lustre,
> hence I'd leave fixing the bugs in lustre to them ;)
> 
> I'm working with the research group for scientific computing on the University
> of Hamburg on the German Climate Computing Centre. The research group is working
> with high performance storage systems etc. In this case, we investigate
> data reduction techniques in behalf of the increasing gap between computational speed,
> network speed and storage capacity. That's why we're ultimately aiming
> for compression support in lustre.
> 
> Initial studies have shown that an adequate compression ratio for scientific data
> can be archieved using LZ4. Since the currently available version of LZ4
> in the kernel is about three years old, we would love if you accept 
> our work on getting a more current version into the kernel.

But the LZ4 code isn't really used much in the kernel today, so if you
change it, what is really going to benefit?  And if you want to archive
things, you aren't using the in-kernel lz4 code, right?

If you want to add support for compression for lustre, great, I suggest
working with those developers, but note, I can't take any new features
for lustre until that code is out of drivers/staging/.

> >> Also, it will be useful for other users of LZ4 compression,
> >> as with LZ4 fast it is possible to enable applications to use fast and/or high
> >> compression depending of the usecase. E.g. a developer can use very
> >> high compression (low acceleration) for sending data over a network with
> >> limited rate of transmission or he trades the compression ratio for higher
> >> compression speed.
> >
> > This whole patch series is broken, always test-build your code, there's
> > nothing we could do with these patches even if we wanted to :(
> >
> > greg k-h
> >
> 
> I'm sorry, this is my first patchset, so please be kind :(

Not a problem, just always test-build your patches, in series, so that
we don't get grumpy for obvious problems :)

thanks,

greg k-h