Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752115AbdHRPin (ORCPT ); Fri, 18 Aug 2017 11:38:43 -0400 Received: from mx2.suse.de ([195.135.220.15]:46786 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750881AbdHRPik (ORCPT ); Fri, 18 Aug 2017 11:38:40 -0400 Date: Fri, 18 Aug 2017 17:37:14 +0200 From: David Sterba To: Giovanni Cabiddu Cc: Nick Terrell , "Austin S . Hemmelgarn" , Herbert Xu , "kernel-team@fb.com" , Chris Mason , Yann Collet , Adam Borowski , David Sterba , "squashfs-devel@lists.sourceforge.net" , "linux-btrfs@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-crypto@vger.kernel.org" , Weigang Li , Brian Will , Brian A Keating , Giovanni Cabiddu Subject: Re: [PATCH v3 3/4] btrfs: Add zstd support Message-ID: <20170818153714.GZ2866@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Giovanni Cabiddu , Nick Terrell , "Austin S . Hemmelgarn" , Herbert Xu , "kernel-team@fb.com" , Chris Mason , Yann Collet , Adam Borowski , "squashfs-devel@lists.sourceforge.net" , "linux-btrfs@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-crypto@vger.kernel.org" , Weigang Li , Brian Will , Brian A Keating , Giovanni Cabiddu References: <20170720212743.3351201-1-terrelln@fb.com> <20170720212743.3351201-4-terrelln@fb.com> <20170725231929.GA28789@silv-upstream1.ir.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170725231929.GA28789@silv-upstream1.ir.intel.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1266 Lines: 22 On Wed, Jul 26, 2017 at 12:19:29AM +0100, Giovanni Cabiddu wrote: > Hi Nick, > > On Thu, Jul 20, 2017 at 10:27:42PM +0100, Nick Terrell wrote: > > Add zstd compression and decompression support to BtrFS. zstd at its > > fastest level compresses almost as well as zlib, while offering much > > faster compression and decompression, approaching lzo speeds. > Can we look at integrating the zstd implementation below the acomp API > available in the crypto subsystem? > (https://github.com/torvalds/linux/blob/master/crypto/acompress.c) > Acomp was designed to provide a generic and uniform API for compression > in the kernel which hides algorithm specific details to frameworks. > In future it would be nice to see btrfs using exclusively acomp > for compression. This way when a new compression algorithm is exposed > through acomp, it will be available immediately in btrfs. The compression algorithm is considered part of the filesystem format and must be covered by an incompatibility bit. Regarding the acomp API, I don't see much point adding the extra abstraction layer for the two currently supported algorithms. We only call 2 functions, for compression and decompression, no need to allocate the acomp helper structures and call the functions indirectly.