From: Theodore Ts'o <tytso@mit.edu>
To: George Spelvin <linux@horizon.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [RFC] mke2fs -E hash_alg=siphash: any interest?
Date: Sun, 21 Sep 2014 13:55:15 -0400 [thread overview]
Message-ID: <20140921175515.GA30646@thunk.org> (raw)
In-Reply-To: <20140921095339.9074.qmail@ns.horizon.com>
On Sun, Sep 21, 2014 at 05:53:39AM -0400, George Spelvin wrote:
>
> Basically, it offers security similar to teahash with a faster, and better
> studied, primitive designed specifically for this application.
>
> I'm thinking of turning this into a patch for ext2utils and fs/ext4.
>
> Could I ask what the general level of interest is? On a scale of "hell,
> no, not more support burden!" to "thank you, I've been meaning to find
> time to add that!"
I'm certainly not against adding a new hash function. The reality is
that it would be quite a while before we could turn it on by default,
because of the backwards compatibility concerns.
The question I would ask is whether we can show an anctual performance
improvement with the hash being used in situ. Let's give it the best
possible chance of making a difference; let's assume a RAM disk with a
very metadata intensive benchmark, with journalling turned off. What
sort of difference would we see, either in terms of system CPU time,
wall clock time, etc.?
The results of such a benchmark would certainly make a difference in
how aggressively we might try to phase in a new hash algorithm.
Cheers,
- Ted
next prev parent reply other threads:[~2014-09-21 17:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-21 9:53 [RFC] mke2fs -E hash_alg=siphash: any interest? George Spelvin
2014-09-21 17:55 ` Theodore Ts'o [this message]
2014-09-21 21:04 ` linux
2014-09-21 22:08 ` TR Reardon
2014-09-22 2:31 ` George Spelvin
2014-09-22 17:09 ` Theodore Ts'o
2014-09-22 23:14 ` George Spelvin
2014-09-22 1:17 ` Theodore Ts'o
2014-09-23 22:25 ` Andreas Dilger
2014-09-23 23:00 ` George Spelvin
2014-09-23 23:22 ` Theodore Ts'o
2014-09-24 0:37 ` George Spelvin
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=20140921175515.GA30646@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=linux@horizon.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.