Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756388Ab1DGRLM (ORCPT ); Thu, 7 Apr 2011 13:11:12 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:40605 "EHLO rcsinet10.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756237Ab1DGRLL (ORCPT ); Thu, 7 Apr 2011 13:11:11 -0400 Message-ID: <4D9DF01C.6050506@oracle.com> Date: Thu, 07 Apr 2011 10:10:52 -0700 From: Sunil Mushran User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: djwong@us.ibm.com CC: "Theodore Ts'o" , Andreas Dilger , linux-ext4 , linux-kernel , Joel Becker Subject: Re: [PATCH 1/2] ext4: Calculate and verify inode checksums References: <20110406224410.GB24354@tux1.beaverton.ibm.com> <20110406224547.GT32706@tux1.beaverton.ibm.com> <4D9D0ADB.9010005@oracle.com> <20110407164006.GC24354@tux1.beaverton.ibm.com> In-Reply-To: <20110407164006.GC24354@tux1.beaverton.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4D9DF022.011A:SCFSTAT5015188,ss=1,fgs=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1456 Lines: 28 On 04/07/2011 09:40 AM, Darrick J. Wong wrote: > Yes, I see that jbd2 has triggers, looks like a nifty feature. I suppose if I > went with that approach I'd still have to calculate the checksum in > ext4_do_update_inode in the nojournal case, and in the journal case I'd write a > trigger that would figure out which inodes in a given buffer are actually dirty > and compute their checksums. Yes, you could use a in-mem flag (set in update, cleared in trigger) to identify dirty inodes. The discussion on stable pages could be relevant for the nojournal case. > > That said, I haven't really quantified the performance impact of this naive > approach yet, so I wonder -- did you see a similar scenario with ocfs2, and > what kind of performance increase did you get by adapting the code to use the > jbd2 trigger? If there's potentially a large increase, it would be interesting > to apply the same conversion to the group descriptor checksumming code too. Joel Becker may remember the overhead. He wrote the patch. That said we have few differences. ocfs2 has larger (blocksized) inodes. Also, it computes ECC. The code is in fs/ocfs2/blockcheck.c. As in, you may want to generate ext4 specific numbers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/