From owner-freebsd-current@FreeBSD.ORG  Sun Oct 16 22:58:15 2005
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
X-Original-To: freebsd-current@FreeBSD.org
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 8B24116A41F;
	Sun, 16 Oct 2005 22:58:15 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 07AEB43D46;
	Sun, 16 Oct 2005 22:58:14 +0000 (GMT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j9GMvtIo060326;
	Sun, 16 Oct 2005 15:57:59 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200510162257.j9GMvtIo060326@gw.catspoiler.org>
Date: Sun, 16 Oct 2005 15:57:55 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: dillon@apollo.backplane.com
In-Reply-To: <200510162244.j9GMimWx037396@apollo.backplane.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Cc: freebsd-current@FreeBSD.org, obrien@FreeBSD.org
Subject: Re: [PANIC] ufs_dirbad: bad dir
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Oct 2005 22:58:15 -0000

On 16 Oct, Matthew Dillon wrote:
>     Ach.  sigh.  Another false alarm.  Sorry.  The code is fine.  It's
>     because the 'end' block is calculated inclusively, e.g.
>     end_lbn = start_lbn + len - 1.  I'm still investigating it.
> 
>     There is a bug if the range reallocblks is called with spans
>     more then two blockmaps, but I don't think that case can occur in real
>     life due to limitations in the range passed by the caller.  Probably
>     worth a KASSERT, though.

Is there any correlation between this problem and the file system block
size?  I've *never* encountered this problem, but I've only used block
sizes up to 16K, and mostly just 4K and 8K.  I seem to have a dim memory
of a mention of problems of some sort with large block sizes.