From owner-svn-src-head@FreeBSD.ORG Sun Apr 4 21:11:13 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A378C106564A; Sun, 4 Apr 2010 21:11:13 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9B58FC0A; Sun, 4 Apr 2010 21:11:12 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA29759; Mon, 05 Apr 2010 00:11:08 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NyX64-000CmQ-2R; Mon, 05 Apr 2010 00:11:08 +0300 Message-ID: <4BB9006A.8080301@freebsd.org> Date: Mon, 05 Apr 2010 00:11:06 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Peter Jeremy References: <201004030839.o338d0VV032828@svn.freebsd.org> <20100404210314.GH86236@server.vk2pj.dyndns.org> In-Reply-To: <20100404210314.GH86236@server.vk2pj.dyndns.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r206129 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 21:11:13 -0000 on 05/04/2010 00:03 Peter Jeremy said the following: > On 2010-Apr-03 08:39:00 +0000, Andriy Gapon wrote: >> Author: avg >> Date: Sat Apr 3 08:39:00 2010 >> New Revision: 206129 >> URL: http://svn.freebsd.org/changeset/base/206129 >> >> Log: >> vn_stat: take into account va_blocksize when setting st_blksize >> >> As currently st_blksize is always PAGE_SIZE, it is playing safe to not >> use any smaller value. For some cases this might not be optimal, but >> at least nothing should get broken. > > I haven't verified it but, based on a quick look at the change, I > suspect this will trigger the problem in bin/144446. Quick summary: > db(3) has restrictions on its internal bucket size but initializes it > from st_blksize with no sanity checking and ZFS can report blocksizes > outside the allowed bucket size range for db(3). > Thank you for pointing this out. If no one objects or provides a better patch, I will commit yours. -- Andriy Gapon