All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Joel Reardon <joel@clambassador.com>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] UBIFS: add crypto lookup field to tree node cache
Date: Mon, 14 May 2012 21:28:26 +0300	[thread overview]
Message-ID: <1337020106.2042.2.camel@koala> (raw)
In-Reply-To: <alpine.DEB.2.00.1205141907290.12448@eristoteles.iwoars.net>

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

On Mon, 2012-05-14 at 19:20 +0200, Joel Reardon wrote:
> The long long is divided as follows:
> 32 bits for the (KSA-relative) LEB number, 32 bits for the offset in the
> leb where the key is found. So its the same as the lnum/offs for the
> current one. Theres substancial compression though, that is available,
> since theres likely not more than 2^^32 LEBS for the KSA and the number of
> bits needed for key offset is LEB_SHIFT - 4.
> 
> Is 32 bits sufficient to address all keys:
> one key per datanode means 4096 * 2^32 = 2^44, so only 16 TB available
> for 32 bit key addresses.
> 
> Though there is similar waste for lnum/offs as well. Perhaps zbranches can
> be stored as a u8[] and demarshalled with bit-op macros when needed for
> computations.

OK, thanks for explanation. Why not to then store 2x32-bit fields
instead, which is consistent with the current style? Why "long long"?

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-05-14 18:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-11 11:24 [PATCH] UBIFS: add crypto lookup field to tree node cache Joel Reardon
2012-05-14 13:21 ` Artem Bityutskiy
2012-05-14 17:20   ` Joel Reardon
2012-05-14 18:28     ` Artem Bityutskiy [this message]
2012-05-14 18:45       ` Joel Reardon
2012-05-14 19:14         ` Artem Bityutskiy
2012-05-15  6:21 ` Artem Bityutskiy

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=1337020106.2042.2.camel@koala \
    --to=dedekind1@gmail.com \
    --cc=joel@clambassador.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    /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.