Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 30 Jul 2001 12:05:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 30 Jul 2001 12:05:21 -0400 Received: from roc-24-169-102-121.rochester.rr.com ([24.169.102.121]:1299 "EHLO roc-24-169-102-121.rochester.rr.com") by vger.kernel.org with ESMTP id ; Mon, 30 Jul 2001 12:05:08 -0400 Date: Mon, 30 Jul 2001 12:04:08 -0400 From: Chris Mason To: Andrew Morton cc: Hans Reiser , Joshua Schmidlkofer , kernel , "Gryaznova E." , "Vladimir V. Saveliev" Subject: Re: ReiserFS / 2.4.6 / Data Corruption Message-ID: <305320000.996509048@tiny> In-Reply-To: <3B65818D.13AA5A1D@zip.com.au> X-Mailer: Mulberry/2.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Original-Recipient: rfc822;linux-kernel-outgoing On Tuesday, July 31, 2001 01:47:25 AM +1000 Andrew Morton wrote: > Chris Mason wrote: >> >> On Saturday, July 28, 2001 03:28:05 AM +1000 Andrew Morton >> wrote: >> >> [ patch to trigger data writes before commit in reiserfs ] >> >> > >> > There's no disruption to disk format - it just simulates >> > the user typing `sync' at the right time. I think the >> > concept is sound, and I'm sure Chris can find a more efficient >> > way... >> >> Well, its gets points for simplicity ;-) > > Well, I tried system("/bin/sync"); but that didn't link. > >> What I think we need is for commit_write to put new buffers a per super >> list of new buffers, and then the journal code can flush that list on >> commit. > > whee. Now there's an idea - If the fs keeps track of all its inodes > then you can traverse those and flush out the i_dirty_buffers ring > on each one. It won't work as well in a generic sense, but I was planning on just using the b_inode_buffers. Instead of going onto the inode's dirty buffer list, they go onto this special list instead (the reiserfs journal already has a dummy inode used for this). The advantage is that nothing extra is needed on the buffer head, but the disadvantage is the buffer doesn't go on the inode's list. Somebody needs to flush the new list on fsync and such. It works for reiserfs, but not in general. I think you're right about being able to clear BH_New once get_block tests it. Unless someone comes up with a reason against, I'll test it out. I'm guessing that we are wasting time rerunning unmap_underlying_metadata on buffers marked BH_New. -chris - 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/