From patchwork Thu Mar 10 14:28:15 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Artem Bityutskiy X-Patchwork-Id: 86289 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 01ED4B6F73 for ; Fri, 11 Mar 2011 01:31:22 +1100 (EST) Received: from canuck.infradead.org ([2001:4978:20e::1]) by bombadil.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1PxgsT-0007rB-TD; Thu, 10 Mar 2011 14:30:10 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1PxgsQ-0006dr-00; Thu, 10 Mar 2011 14:30:06 +0000 Received: from mail-ew0-f49.google.com ([209.85.215.49]) by canuck.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1PxgsK-0006dP-Ae for linux-mtd@lists.infradead.org; Thu, 10 Mar 2011 14:30:01 +0000 Received: by ewy3 with SMTP id 3so610054ewy.36 for ; Thu, 10 Mar 2011 06:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:reply-to:to:cc:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=+IgjfduumgUmQ5yAXTcWjaCvf5Ly71mVsHqErYSVaes=; b=B9RlAzhwxiR7AJ6llPR7ZfUA9k7oTdEky8giTBebFcYAAnscEBw+Y6imflw7MTyGIW NwWgxJY/0sirlQABNvOpEQk4gPplUTdfzcqMAnmNOXnUyHDsbFoMkDGIbEYe5yx1ZSBD vZBRdyFKdvq3I3ZAfUaMTQVlZubmESfEDndRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:reply-to:to:cc:in-reply-to:references:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; b=WCXDrnNtbHnnL/8nLXauVKjO9uDH3GGQ2U9aGde6336Jxtpi2vXi9yWMovcjI2klBJ B9thyPpruoUFEOoij5yuP3TYmcghzAk0J3YMytcI61C+qjA4xre+iEqCHsakItnHEoSU hmeobE2brW+2Y7Xs3FPJIZYCNJ7JLRSQJvgUI= Received: by 10.223.17.17 with SMTP id q17mr1578986faa.123.1299767387142; Thu, 10 Mar 2011 06:29:47 -0800 (PST) Received: from ?IPv6:::1? (shutemov.name [188.40.19.243]) by mx.google.com with ESMTPS id n3sm1399936fax.31.2011.03.10.06.29.45 (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 06:29:46 -0800 (PST) Subject: Re: UBIFS defaults? From: Artem Bityutskiy To: "Hunter Adrian (Nokia-MS/Helsinki)" In-Reply-To: <1299675687.2741.14.camel@localhost> References: <1299675687.2741.14.camel@localhost> Date: Thu, 10 Mar 2011 16:28:15 +0200 Message-ID: <1299767295.6676.26.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110310_093000_637772_9A509D13 X-CRM114-Status: GOOD ( 24.03 ) X-Spam-Score: 1.4 (+) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (1.4 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.215.49 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is freemail (dedekind1[at]gmail.com) 2.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (dedekind1[at]gmail.com) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Cc: Bhavesh Parekh , linux-mtd X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dedekind1@gmail.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Wed, 2011-03-09 at 15:01 +0200, Artem Bityutskiy wrote: > Hi, > > currently, UBIFS checks data CRC on read by default, i.e., the > 'chk_data_crc' mount option is the default one. This makes people who > apply benchmarks less happy, because they just use the defaults. > > Should we make the 'no_chk_data_crc' mount option to be the default > instead? The rationale is that people who do care to read the > documentation can switch to 'chk_data_crc' if they need, and people who > do quick UBIFS evaluation will end up with faster read speed by default. > > See this section for more information about the 'no_chk_data_crc' mount > option: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_checksumming > > Would be nice to hear UBIFS users' opinion. From f7a2d4a6dea3fcec4612aa81baabf8aae0040896 Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Thu, 10 Mar 2011 16:26:32 +0200 Subject: [PATCH] UBIFS: do not check data crc by default Change the default UBIFS behavior WRT data CRC checking. Currently, UBIFS checks data CRC when reading, which slows it down quite a bit, and this is the default option. However, it looks like in average user does not need this feature and would prefer faster read speed over extra reliability. And this seems to be de-facto standard that file-systems do not check data CRC every time they read from the media. Thus, make UBIFS default behavior so that it does not check data CRC. This corresponds to the no_chk_data_crc mount option. Those users who need extra protection can always enable it using the chk_data_crc option. Please, read more information about this feature here: http://www.linux-mtd.infradead.org/doc/ubifs.html#L_checksumming Signed-off-by: Artem Bityutskiy --- Documentation/filesystems/ubifs.txt | 4 ++-- fs/ubifs/super.c | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/filesystems/ubifs.txt b/Documentation/filesystems/ubifs.txt index 12fedb7..d7b13b0 100644 --- a/Documentation/filesystems/ubifs.txt +++ b/Documentation/filesystems/ubifs.txt @@ -82,12 +82,12 @@ Mount options bulk_read read more in one go to take advantage of flash media that read faster sequentially no_bulk_read (*) do not bulk-read -no_chk_data_crc skip checking of CRCs on data nodes in order to +no_chk_data_crc (*) skip checking of CRCs on data nodes in order to improve read performance. Use this option only if the flash media is highly reliable. The effect of this option is that corruption of the contents of a file can go unnoticed. -chk_data_crc (*) do not skip checking CRCs on data nodes +chk_data_crc do not skip checking CRCs on data nodes compr=none override default compressor and set it to "none" compr=lzo override default compressor and set it to "lzo" compr=zlib override default compressor and set it to "zlib" diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index b722ebc..e5dc1e1 100644 --- a/fs/ubifs/super.c +++ b/fs/ubifs/super.c @@ -1985,6 +1985,7 @@ static int ubifs_fill_super(struct super_block *sb, void *data, int silent) INIT_LIST_HEAD(&c->old_buds); INIT_LIST_HEAD(&c->orph_list); INIT_LIST_HEAD(&c->orph_new); + c->no_chk_data_crc = 1; c->vfs_sb = sb; c->highest_inum = UBIFS_FIRST_INO;