[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: commit: ldap/doc/man/man5 slapd-bdb.5
Hallvard B Furuseth wrote:
Howard Chu writes:
The default in slapd is an explicit 4KB.
Duh, the patch I was replying to said that...
BTW, if back-bdb and dbpagesize measure pages in 1K block units,
back-bdb must ensure Berkeley DB doesn't pick 512-byte blocks.
If you set an explicit size, BDB doesn't get to pick, so that's irrelevant.
Besides, no worthwhile filesystems in common use today use 512 byte blocks.
The only thing that would possibly use such a size is FAT12 on a 360K floppy
disk. (As I recall, by the time we got to 1.2MB floppies everyone had already
switched to FAT16...) Anything using 512 byte blocks is obviously not suitable
for database use.
I agree that defaulting to the underlying FS block size might be
better,
Actually that's stronger that I suggested. It's been a while
since I read the tuning guides, but I thought it was a trade-off
for what one cares most about. Performance, integrity, space.
Maybe whether a database has many index keys with large ID lists.
Right.
Brainstorming a bit more: For a DB admin, I imagine it could be
nice to allow "I don't care as long as you don't pick too small or
too large pages". I.e. a pagesize range:
dbpagesize [ * | file ] { integer | [integer]-[integer] }
"*" = all files not overridden by a "file" configuration.
pagesize = (filesys_pagesize<= range_min ? range_min :
filesys_pagesize>= range_max ? range_max :
filesys_pagesize);
I have no idea if that's useful enough to bother with though. If
one tries to write a template for a "general" config, it might be
better to write a script which dynamically creates one.
Most people simply shouldn't touch this setting. If "I don't care" is true,
then "don't touch it."
Anyone who changes this setting should have read all of the relevant BDB docs
first, to understand the risks and tradeoffs. At that point, they should
choose a specific number, none of this fuzzy approximate range stuff.
People who are running into frequent DB overflow conditions probably should be
redesigning their DIT, not messing with the DB page sizes...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/