From owner-svn-src-all@FreeBSD.ORG Mon Apr 5 08:27:15 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99C9F1065675; Mon, 5 Apr 2010 08:27:15 +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 57FDB8FC0C; Mon, 5 Apr 2010 08:27:13 +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 LAA04757; Mon, 05 Apr 2010 11:27: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 1NyheF-000FFr-Va; Mon, 05 Apr 2010 11:27:08 +0300 Message-ID: <4BB99EDB.8030105@freebsd.org> Date: Mon, 05 Apr 2010 11:27:07 +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> <4BB9006A.8080301@freebsd.org> <20100404212742.GJ2415@deviant.kiev.zoral.com.ua> <20100404221232.GJ86236@server.vk2pj.dyndns.org> In-Reply-To: <20100404221232.GJ86236@server.vk2pj.dyndns.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 08:27:15 -0000 on 05/04/2010 01:12 Peter Jeremy said the following: > On 2010-Apr-05 00:27:42 +0300, Kostik Belousov wrote: >> On Mon, Apr 05, 2010 at 12:11:06AM +0300, Andriy Gapon wrote: >>> on 05/04/2010 00:03 Peter Jeremy said the following: >>>> On 2010-Apr-03 08:39:00 +0000, Andriy Gapon wrote: >>>>> vn_stat: take into account va_blocksize when setting st_blksize > ... >>>> 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. >> I do not think this is very satisfying solution. Pre-patched libc >> still suffer from the problem. You cannot run stable/8 libc on this >> kernel. > > Firstly, has someone with a post-r206129 kernel verified that it > does actually trigger the issue I reported in bin/144446? I'm not > in a position to do so easily and it's possible that the problem > is masked elsewhere. Sorry for my lack of knowledge, but what is the best way to test this? As I understand, a new db needs to be initialized in an existing file? > Also, Kostik's comment is a slight exaggeration: You can't create a > db(3) database from scratch in a ZFS filesystem using db(3) defaults. > Note that as of now, it's exactly the same situation as running > -current libc with a post-r206129 kernel. Additionally, as noted above (and if I am not mistaken), the problem would manifest itself when creating a new db in an existing file and the file has to be large enough. > -current is expected to include occasions of bumpiness so I don't see > this as an immediate reason to revert r206129 - though if buildworld > or installworld are affected, it at least needs a heads-up. OTOH, I > think some care needs to taken over any MFC of this change. At the > very least, the db(3) problem needs to be fixed and there probably > needs to be an extended shakedown of r206129 to ensure that there > aren't any other similar nasties lurking elsewhere. I agree about the MFC. > The problem I reported in bin/144446 is a bug in a userland utility > and IMHO, it's not the kernel's responsibility to work around userland > bugs. But Kostik has a good point here. Value of st_blksize is kind of interface from kernel to userland and when it's changing it could be considered an A?I change with all the release engineering consequences. -- Andriy Gapon