svn commit: r206129 - head/sys/kern

[Andriy Gapon]

on 05/04/2010 01:12 Peter Jeremy said the following:
> On 2010-Apr-05 00:27:42 +0300, Kostik Belousov <kostikbel at 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 at 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