On Wed, Dec 11, 2002 at 12:16:41PM -0800, Greywolf wrote:
> On Wed, 11 Dec 2002, Juergen Hannken-Illjes wrote:
> 
> #     fs block size is 65536 (2^16). This is the default bucket size.
> #
> # lib/libc/db/hash/hash_page.c contains:
> #
> #     #define PAGE_INIT(P) { \
> #     	((u_int16_t *)(void *)(P))[0] = 0; \
> #     	((u_int16_t *)(void *)(P))[1] = hashp->BSIZE - 3 * sizeof(u_int16_t); \
> #     	((u_int16_t *)(void *)(P))[2] = hashp->BSIZE; \
> #
> # which becomes:
> #
> # 	((u_int16_t *)(void *)(P))[0] = 0
> # 	((u_int16_t *)(void *)(P))[1] = 65530;
> # 	((u_int16_t *)(void *)(P))[2] = 65536; <== this becomes 0!!
> #
> # P[1] is the amount of free space and P[2] is the free pointer.
> #
> # What is the best solution to get rid of this bug?
> #
> # Don't allow bucket size > 32768 (2^15)?
> # Set P[1] = 65529, P[2] = 65535  and discard the last byte of a page?
> 
> Curiously (bear with my lack of education), what would be the effect
> of increasing the bucket size?  Would this break things in a horrible
> way, or a horribly subtle way, or would it destroy compatibility,
> or is this something that will eventually need to be addressed anyway?

This would be a DEcrease. Currently MAX_BSIZE is 65536 (2^16).

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)