From patchwork Thu Jun 7 09:06:08 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Artem Bityutskiy X-Patchwork-Id: 163546 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 0BFE9B6FFC for ; Thu, 7 Jun 2012 19:06:48 +1000 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1ScYeT-0001en-H1; Thu, 07 Jun 2012 09:05:09 +0000 Received: from mga02.intel.com ([134.134.136.20]) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1ScYeH-0001cs-Kp for linux-mtd@lists.infradead.org; Thu, 07 Jun 2012 09:04:58 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 07 Jun 2012 02:04:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="149328275" Received: from blue.fi.intel.com ([10.237.72.50]) by orsmga001.jf.intel.com with ESMTP; 07 Jun 2012 02:04:53 -0700 From: Artem Bityutskiy To: Joel Reardon Subject: [PATCH 4/4] UBIFS: add TOTOs for Joel Date: Thu, 7 Jun 2012 12:06:08 +0300 Message-Id: <1339059968-25753-4-git-send-email-dedekind1@gmail.com> X-Mailer: git-send-email 1.7.10 In-Reply-To: <1339059968-25753-1-git-send-email-dedekind1@gmail.com> References: <1339059968-25753-1-git-send-email-dedekind1@gmail.com> X-Spam-Note: CRM114 invocation failed X-Spam-Score: -5.0 (-----) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-5.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [134.134.136.20 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dedekind1[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 0.8 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (dedekind1[at]gmail.com) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.9 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list Cc: MTD Maling List X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org From: Artem Bityutskiy Signed-off-by: Artem Bityutskiy --- fs/ubifs/sb.c | 17 +++++++++++++++++ fs/ubifs/ubifs.h | 6 ++++++ 2 files changed, 23 insertions(+) diff --git a/fs/ubifs/sb.c b/fs/ubifs/sb.c index 91c78e7..20eec40 100644 --- a/fs/ubifs/sb.c +++ b/fs/ubifs/sb.c @@ -73,6 +73,23 @@ */ static int calc_ksa_lebs(struct ubifs_info *c, int leb_cnt) { + /* TODO: I do not think this is correct. The data node size varies from + * UBIFS_DATA_NODE_SZ to UBIFS_MAX_DATA_NODE_SZ. Indeed, I can fill my + * file-system with millions of files with size of 1 byte. But you + * assume that data nodes are 4KiB in size, which is wrong. Remember + * that we compress the data? Or I misunderstoos something? + * + * Or even worse, if I have a huge file containing only 1's or anything + * else which perfectly well compresses, and I fill all space with this + * file, then we'll end up with huge amount of tiny data nodes, and + * you'll need one key per data node. + * + * So, the most pessimistic thing is to assume the minimum data node + * size of UBIFS_DATA_NODE_SZ, right? */ + + /* TODO: note, the leb_cnt * UBIFS_CRYPTO_KEYSIZE part may easily + * overflow because it will be done as 32-bit multiplication with a + * 32-bit result. So this is not really correct */ return (leb_cnt * UBIFS_CRYPTO_KEYSIZE) >> UBIFS_BLOCK_SHIFT; } diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h index f34ab84..2b43107 100644 --- a/fs/ubifs/ubifs.h +++ b/fs/ubifs/ubifs.h @@ -167,11 +167,17 @@ /* * Constant number of KSA LEBS to add to computed value, ensuring two plus a * checkpoint LEB. + * + * TODO: please, improve the comment to make it easier to understand why you + * need 3 extra LEBs. Also the checkpoint LEB is something new to me. */ #define UBIFS_KSA_ADD_LEBS 3 /* * KSA LEBS is 1.125 * the computed min to allow unused keys when the drive is * full. This shift is used to compute 0.125 * LEBS. + * + * TODO: looks like blach magic. Could the comment be improved to make this + * easy to understand why we need unused keys? */ #define UBIFS_KSA_LEBS_SCALE_SHIFT 3