linux-kernel - Re: [PATCH] zram: add zstd to the supported algorithms list

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: <20170825052717.GD5876@jagdpanzerIV.localdomain>
Date:   Fri, 25 Aug 2017 14:27:17 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Minchan Kim <minchan@...nel.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, Nick Terrell <terrelln@...com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCH] zram: add zstd to the supported algorithms list

On (08/25/17 14:06), Sergey Senozhatsky wrote:
> > Off-topic:
> > 
> > In all ways, zstd beats deflate. Nick, Right?
> > 
> > With zstd, I doubt we should show "deflate" to user. Many options just
> > make user confused.
> > The inflate have been there for representing high comp ratio but slower
> > speed. However, zstd is better unconditionally compared to deflate
> > so how about replacing deflate with zstd?
> > 
> > Sergey, what do you think about it?
> 
> hmmm... frankly, I don't think it would confuse anyone. the code is
> there - compiled - anyway, and the module is visible in /proc/crypto
> etc. if we will make it unavailable in zram then this can be confusing,
> probably... if anyone ever pays any attention at all. my guess is that
> people look what's in /sys/block/zram0/comp_algorithm just once, then
> they set up a create-zram script/systemd unit file/etc. and forget
> about it.
> 
> cryto API is just a wrapper and it calls lib/comp_foo to do the actual
> work, and that lib/comp_foo *may be* can be implemented as a H/W (not
> S/W) compressing backend. well, who knows.

but I can remove deflate, if you insist. sure.

	-ss