Sergey Poznyakoff wrote:
Linda A. Walsh ha escrit:
Already attended to, but no response... Maybe its no longer supported? It is. I'll attend the matter as soon as my schedule permits.
Does anyone know of a test suite for gdbm to test for sanity and previous version compatibility? The attached patch allows perl to build and successfully test on my machine (w/stat-blocksize=768K) that is used when using the "compat" libs as well using gdbm with a 0-record size (0=auto-select based on stat-blocksize). It keeps the blocksize the same, but bails out of the auto-size algorithm when the dirsize is > 50% of the blocksize. I.e. before, it continued until dirsize was >= blocksize, now it will stop if 2*dirsize > blocksize. Theoretically, but with no way to really test it, if you are running on a file system with blocksize = 2**X for some integer X, the data and dir blocksizes should remain the same. The downside would be for people for whom the previous algorithm DIDN'T work. Their dir entries could be about 50% of what they could be if the full dir-block was used (but it cuts out at the previous power of 2) -- with the datablock size being unchanged. I.e, in my case, w/iosize=768K, the dir will stop @ size 512K leaving 256K entries unused -- but allowing for the DB as a whole to use the optimal I/O size. Would take more work than I care to spend to try to change the various algorithms to use the full space for the dir-entries. I think the area for hashes and data should be fully utilized, as it appeared the sizing problem was in sizing the dir block size upwards by a factor of 2 until it was >= to the iosize (in my case, the dirblock size would have not stopped increasing until 1024K, -- which caused the internal consistency check to fail. Anyway -- testing would be good now - all I know is it let perl pass on build. (about 10 tests failed due to the db problem).