Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754233Ab0BHTDa (ORCPT ); Mon, 8 Feb 2010 14:03:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38768 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750962Ab0BHTD2 (ORCPT ); Mon, 8 Feb 2010 14:03:28 -0500 Message-ID: <4B705FC8.1030407@redhat.com> Date: Mon, 08 Feb 2010 13:02:32 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Andrew Morton CC: tytso@mit.edu, Jan Kara , Christoph Egger , linux-kernel@vger.kernel.org, Kazuo Moriwaka , H Hartley Sweeten , Joel Becker , linux-ext4@vger.kernel.org, vamos@i4.informatik.uni-erlangen.de Subject: Re: [PATCH] obsolete config in kernel source (BUFFER_DEBUG) References: <20100205131333.GB6540@faui49.informatik.uni-erlangen.de> <20100208135629.GD4321@quack.suse.cz> <20100208155031.GK4494@thunk.org> <20100208105828.1136310a.akpm@linux-foundation.org> In-Reply-To: <20100208105828.1136310a.akpm@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2355 Lines: 70 Andrew Morton wrote: > On Mon, 8 Feb 2010 10:50:31 -0500 tytso@mit.edu wrote: > >> I don't have an objection with removing this, but does anyone have the >> latest version of akpm's buffer debugging patches? > > My version is datestamped four years ago :( It normally forward-ports > fairly easily. > >> I *think* what happened is that akpm forward ported the removed buffer >> debugging patches, or maybe rewrote it from scratch, but for whatever >> reason they never made back into mainline. Maybe they were too ugly >> to live in mainline, but they have been really handy on occasion. > > I think Eric Sandeen might have a fresher version. If "fresh" means 2.6.18, I might ;) But yes they sure have come in handy from time to time. > Nowadays it should > be done with the tracing infrastructure, I guess. that's kind of what I was thinking, too. -Eric > Although that > infrastructure may not be able to do this - the ext3 debug patch > recorded an LRU array of the below structs within every buffer_head. > The various BUFFER_TRACE macros would emit a new record into the tail of the > target bh's b[] ring. > > struct buffer_history { > struct buffer_history_item { > char *function; > char *info; > unsigned long b_state; > unsigned b_list:3; > unsigned b_jlist:4; > unsigned pg_dirty:1; > unsigned cpu:3; > unsigned b_count:8; > unsigned long b_blocknr; /* For src != dest */ > #if defined(CONFIG_JBD) || defined(CONFIG_JBD_MODULE) > unsigned b_jcount:4; > unsigned b_jbd:1; > unsigned b_transaction:1; > unsigned b_next_transaction:1; > unsigned b_cp_transaction:1; > unsigned b_trans_is_running:1; > unsigned b_trans_is_committing:1; > void *b_frozen_data; > void *b_committed_data; > #endif > } b[BUFFER_HISTORY_SIZE]; > unsigned long b_history_head; /* Next place to write */ > unsigned long b_history_tail; /* Oldest valid entry */ > }; > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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/