Date: Mon, 5 Apr 2010 08:12:32 +1000 From: Peter Jeremy <peterjeremy@acm.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Andriy Gapon <avg@freebsd.org> Subject: Re: svn commit: r206129 - head/sys/kern Message-ID: <20100404221232.GJ86236@server.vk2pj.dyndns.org> In-Reply-To: <20100404212742.GJ2415@deviant.kiev.zoral.com.ua> References: <201004030839.o338d0VV032828@svn.freebsd.org> <20100404210314.GH86236@server.vk2pj.dyndns.org> <4BB9006A.8080301@freebsd.org> <20100404212742.GJ2415@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--iRjOs3ViPWHdlw/I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 =2E.. >> > 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). >>=20 >> 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. 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. -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. 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. --=20 Peter Jeremy --iRjOs3ViPWHdlw/I Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAku5DtAACgkQ/opHv/APuIegqwCfT+ZGgoZyA1TQDgHIHS30qpmx dUUAoLk9nNoBsQhOe1p7Csib8uOpVwtD =/Drm -----END PGP SIGNATURE----- --iRjOs3ViPWHdlw/I--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100404221232.GJ86236>