Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754031AbYHGPCU (ORCPT ); Thu, 7 Aug 2008 11:02:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751586AbYHGPCJ (ORCPT ); Thu, 7 Aug 2008 11:02:09 -0400 Received: from mx1.redhat.com ([66.187.233.31]:60994 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751090AbYHGPCI (ORCPT ); Thu, 7 Aug 2008 11:02:08 -0400 Subject: Re: [PATCH] jbd: abort instead of waiting for nonexistent transactions From: "Stephen C. Tweedie" To: Duane Griffin Cc: linux-kernel , Andrew Morton , linux-ext4@vger.kernel.org, Sami Liedes , Stephen Tweedie In-Reply-To: References: <1217893895-29165-1-git-send-email-duaneg@dghda.com> <1217951437.3886.36.camel@sisko.scot.localnet> Content-Type: text/plain Date: Thu, 07 Aug 2008 16:01:08 +0100 Message-Id: <1218121268.14209.13.camel@sisko.scot.localnet> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-41.el4) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1475 Lines: 39 Hi, On Thu, 2008-08-07 at 01:47 +0100, Duane Griffin wrote: > > Surely we'd be better off detecting this in the first place at mount > > time, not later on during checkpoint? > > Sounds sensible. In fact I've got another patch, waiting for feedback > from the reporter, that adds some very basic validation there (i.e. > first > 0 && last >= first). Not enough, I suspect. I guess we could > do much better? Right: in journal.c we initialise the maximum size of a transaction to journal->j_max_transaction_buffers = journal->j_maxlen / 4; (the logic being that we need the journal to be able to hold an absolute minimum of one full transaction being checkpointed, one being committed, and one being live concurrently for the transaction engine to work correctly, which gives three outstanding transactions; we up that to four to protect against rounding errors and to ensure space for the sequence and commit blocks that take up log space in addition to the journaled buffers themselves.) If, during journal load, that's not enough for a minimum-sized single update, we'll never be able to start some transactions, so that would be a good place to check that we're starting off with a large enough journal. --Stephen -- 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/