From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757303Ab2CWDPr (ORCPT ); Thu, 22 Mar 2012 23:15:47 -0400 Received: from mail-iy0-f174.google.com ([209.85.210.174]:62844 "EHLO mail-iy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752458Ab2CWDPq (ORCPT ); Thu, 22 Mar 2012 23:15:46 -0400 Date: Thu, 22 Mar 2012 20:15:32 -0700 From: Mandeep Singh Baines To: Mikulas Patocka Cc: Mandeep Singh Baines , device-mapper development , Steffen Klassert , Will Drewry , linux-kernel@vger.kernel.org, Elly Jones , Olof Johansson , Andrew Morton , Alasdair G Kergon , Milan Broz , taysom@chromium.org Subject: Re: [dm-devel] [PATCH] dm: remake of the verity target Message-ID: <20120323031532.GP27051@google.com> References: <20120320154159.GD27051@google.com> <20120322174101.GM27051@google.com> MIME-Version: 1.0 In-Reply-To: X-Operating-System: Linux/2.6.38.8-gg683 (x86_64) User-Agent: Mutt/1.5.20 (2009-06-14) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mikulas Patocka (mpatocka@redhat.com) wrote: > > > On Thu, 22 Mar 2012, Mandeep Singh Baines wrote: > > > Mikulas Patocka (mpatocka@redhat.com) wrote: > > > > > > This is improved patch that supports both the old format and the new > > > format. I checked that it is interoperable with with the old Google > > > userspace tool and with the original Google kernel driver. > > > > > > > Thanks much for doing this:) > > > > This looks good but would a prepend/append flag be better? > > It does more than changing prepend/append salt. I changed alignment in the > new format so that it doesn't have to use a multiply instruction. > > In the old format, if digest size is not a power of two, all digests are > placed first and the rest of the block is padded with zeros. In the new > format, each digest is padded with zeros to a power of two. > > For example, when using sha1, the old format padding looks like this: > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbb > bbbbbbbbbbbbbbbbccccccccccccccccccccccccccccccccccccccccdddddddd > dddddddddddddddddddddddddddddddd00000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000 > > ... and the new format padding looks like this: > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa000000000000000000000000 > bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb000000000000000000000000 > cccccccccccccccccccccccccccccccccccccccc000000000000000000000000 > dddddddddddddddddddddddddddddddddddddddd000000000000000000000000 > > The version "0" (first argument in the target line) actually means the old > style padding and the salt is hashed after the data. The version "1" means > new style padding and the salt is hashed before the data. If someone comes > with another format, we can use version "2" for it, etc. > +cc taysom Makes sense. Signed-off-by: Mandeep Singh Baines Speaking of V2, one idea a colleague of mine (taysom) just had was to drop the power of 2 alignment. For SHA-1, this shrinks the tree by 37.5 %. You have to replace the shifts with divides but the reduction in I/O more than makes up. For the different levels, you could pre-calculate the divisor. Regards, Mandeep > Mikulas