Date: Mon, 05 Apr 2010 11:27:07 +0300 From: Andriy Gapon <avg@freebsd.org> To: Peter Jeremy <peterjeremy@acm.org> Cc: Kostik Belousov <kostikbel@gmail.com>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r206129 - head/sys/kern Message-ID: <4BB99EDB.8030105@freebsd.org> In-Reply-To: <20100404221232.GJ86236@server.vk2pj.dyndns.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
on 05/04/2010 01:12 Peter Jeremy said the following: > On 2010-Apr-05 00:27:42 +0300, Kostik Belousov <kostikbel@gmail.com> 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 <avg@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BB99EDB.8030105>