linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Johannes Thumshirn <jthumshirn@suse.de>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>,
	David Sterba <dsterba@suse.com>,
	Linux BTRFS Mailinglist <linux-btrfs@vger.kernel.org>
Subject: Re: [RFC PATCH 3/4] btrfs: use xxhash64 for checksumming
Date: Fri, 26 Jul 2019 15:45:09 +0200	[thread overview]
Message-ID: <20190726134508.GB2868@twin.jikos.cz> (raw)
In-Reply-To: <20190725141837.GA3936@x250.microfocus.com>

On Thu, Jul 25, 2019 at 04:18:37PM +0200, Johannes Thumshirn wrote:
> On Thu, Jul 25, 2019 at 08:02:12PM +0800, Qu Wenruo wrote:
> > 
> > 
> > On 2019/7/25 下午5:33, Johannes Thumshirn wrote:
> > > Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
> > > ---
> > >  fs/btrfs/Kconfig                | 1 +
> > >  fs/btrfs/ctree.h                | 1 +
> > >  fs/btrfs/disk-io.c              | 1 +
> > >  fs/btrfs/super.c                | 1 +
> > >  include/uapi/linux/btrfs_tree.h | 1 +
> > >  5 files changed, 5 insertions(+)
> > > 
> > > diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
> > > index 38651fae7f21..6d5a01c57da3 100644
> > > --- a/fs/btrfs/Kconfig
> > > +++ b/fs/btrfs/Kconfig
> > > @@ -5,6 +5,7 @@ config BTRFS_FS
> > >  	select CRYPTO
> > >  	select CRYPTO_CRC32C
> > >  	select LIBCRC32C
> > > +	select CRYPTO_XXHASH
> > 
> > Just an off topic idea, can we make such CRYPTO_* support configurable?
> > E.g. make something like CONFIG_BTRFS_CRYPTO_XXHASH.
> > 
> > Not sure if everyone would like to pull all hash algorithm.
>  
> This is something I thought about as well, but I was afraid of people shooting
> themselves in the foot if they forget to switch them on and mkfs with the
> wrong option.

> Not sure what's the better way here? Dave?

I'd go to pull everything unconditionally, which means that all
dependent modules are built and does not require the user to tweak the
config.

I understand that there are setups that don't want to provide all hash
algorithms eg. due to space constraints. That will be still possible and
puts the "burden" on the distributor/integrator. Simply don't provide
the .ko files. The crypto API can detect that during mount the shash
descriptor cannot be instantiated and will fail. In specialized setups
this is ok, because lack of the hash algorithm is known.

For everybody else, the filesystem should come with all parts included
so the features work.

The situation with zlib/lzo/zstd is different because we use the library
functions, not the separate .ko modules. This is a bit more convenient.

We don't want to do that with the hash algorithms though because there
are usually optimized verions that we do want to use, and the crypto API
does all the work.

  reply	other threads:[~2019-07-26 13:50 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-25  9:33 [RFC PATCH 0/4] Support xxhash64 checksums Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 1/4] btrfs: turn checksum type define into a union Johannes Thumshirn
2019-07-25 11:08   ` Mike Fleetwood
2019-07-25 11:21     ` Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 2/4] btrfs: create structure to encode checksum type and length Johannes Thumshirn
2019-07-26  3:09   ` Su Yue
2019-07-30 17:25   ` David Sterba
2019-08-12  9:07   ` Nikolay Borisov
2019-08-19  9:15     ` Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 3/4] btrfs: use xxhash64 for checksumming Johannes Thumshirn
2019-07-25 12:02   ` Qu Wenruo
2019-07-25 14:18     ` Johannes Thumshirn
2019-07-26 13:45       ` David Sterba [this message]
2019-07-25  9:33 ` [RFC PATCH 4/4] btrfs: sysfs: export supported checksums Johannes Thumshirn
2019-07-30 17:19   ` David Sterba
2019-07-31  8:06     ` Johannes Thumshirn
2019-08-07 14:10     ` Johannes Thumshirn
2019-08-21 16:19       ` David Sterba
2019-08-12  9:19   ` Nikolay Borisov
2019-08-19  9:15     ` Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 05/17] btrfs-progs: add option for checksum type to mkfs Johannes Thumshirn
2019-07-30 17:36   ` David Sterba
2019-08-12  9:30   ` Nikolay Borisov
2019-07-25  9:33 ` [RFC PATCH 06/17] btrfs-progs: don't blindly assume crc32c in csum_tree_block_size() Johannes Thumshirn
2019-08-12  9:49   ` Nikolay Borisov
2019-07-25  9:33 ` [RFC PATCH 07/17] btrfs-progs: use btrfs_csum_data() in __csum_tree_block_size() Johannes Thumshirn
2019-07-30 17:37   ` David Sterba
2019-07-25  9:33 ` [RFC PATCH 08/17] btrfs-progs: cache csum_type in recover_control Johannes Thumshirn
2019-08-12  9:52   ` Nikolay Borisov
2019-07-25  9:33 ` [RFC PATCH 09/17] progs: pass in a btrfs_mkfs_config to write_temp_extent_buffer Johannes Thumshirn
2019-07-30 17:38   ` David Sterba
2019-08-12  9:56   ` Nikolay Borisov
2019-07-25  9:33 ` [RFC PATCH 10/17] btrfs-progs: add checksum type to checksumming functions Johannes Thumshirn
2019-08-12 10:21   ` Nikolay Borisov
2019-08-26  9:34     ` Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 11/17] btrfs-progs: don't assume checksums are always 4 bytes Johannes Thumshirn
2019-07-25  9:33 ` [RFC PATCH 12/17] btrfs-progs: pass checksum type to btrfs_csum_data() Johannes Thumshirn
2019-08-12 10:51   ` Nikolay Borisov
2019-08-20  9:12     ` Johannes Thumshirn
2019-07-25  9:34 ` [RFC PATCH 13/17] " Johannes Thumshirn
2019-07-25  9:34 ` [RFC PATCH 14/17] btrfs-progs: simplify update_block_csum() in btrfs-sb-mod.c Johannes Thumshirn
2019-08-12 10:53   ` Nikolay Borisov
2019-07-25  9:34 ` [RFC PATCH 15/17] btrfs-progs: update checksumming api Johannes Thumshirn
2019-07-25  9:34 ` [RFC PATCH 16/17] btrfs-progs: add xxhash sources Johannes Thumshirn
2019-07-25  9:34 ` [RFC PATCH 17/17] btrfs-progs: add xxhash64 as checksum algorithm Johannes Thumshirn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190726134508.GB2868@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=dsterba@suse.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).