On Friday 2013-09-06 02:10, Linda Walsh wrote:
Jan Engelhardt wrote:
Your system is known to be broken in various strange ways every now and then.
Any who's system runs without any bugs, might I ask? ;-)
In this case the gdbm package is bugged in a few places.
1) the gdbm_open, which allows specifying a block-size that is used to perform subsequent I/O's take '0' as meaning "use the file system's optimal I/O size as returned by the "stat" call.
I had something like that in the back of the head, but all of - xfs block sizes 512, 1024, 2048, 4096 - ext4 block sizes 1024, 2048, 4096 - btrfs block size 4096 ran your test program well.
The current gdbm code requires that the record size be a power of 2.
I have yet to see a filesystem whose ideal IO size, especially if it is derived from the fs block/sector/whatever size, is not a power of 2. But there is a first time for everything. Are you on some odd flash filesystem, perhaps?
Looking at the source worked better as gdb stepped over the gdbmopen call rather than into it (maybe I didn't have the right debug packages loaded, so gdb ignored my request to "step- into?" the affected routine.
For stepping, having gdbm-debugsource in addition to gdbm-debuginfo/libgdbm3-debuginfo is a must-have.
While building that way, can be a positive step, testing that way is like testing a car's gas mileage by running the car at 'idle'. Real world numbers tend to vary a bit.
Unfortunately, determing mileage works the same way - also in a clean room, too clean in fact :( "Despite economical driving style and avoiding phases of leadfooting, fuel consumption is 25% above the advertised mileages." - http://www.spiegel.de/auto/aktuell/studie-des-icct-zum-realen-spritverbrauch... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org