On May 21, 2010, at 7:35 PM, Marc MERLIN wrote:
> Howdy,
>
> So running most rpm versions from this century :) creates
> /var/lib/rpm/__db.00? when accessing the rpm dbs.
>
> My understanding is that they are a temporary index created by the DB
> libraries and I know they get recreated as needed.
>
Nope. There are (at least) 3 RPM user visible uses of __db* files, none of them
"temporary" or "index":
1) a version stamp
2) names of locks (and with thread_count, "stale lock" registration
for clean-up after exceptional conditions like reboot and segfault
and programmer error). Note "names", not the locks themselves.
3) data caching
(there are other uses, but the above are the most important for a DB_INIT_CDB
concurrent
access model used in "legacy" rpmdb's. (@rpm5.org uses a different model now,
with full ACID proerties).
> I however have 3 questions I wasn't able to answer because I manage
> machines where most of the system is rsynced (including packages and the
> rpm DB).
>
> 1) can I configure rpm and/or the DB lib not to create those files?
> (they cause issues when we look at a 32bit image on a 64bit system
> for instance since rpm64 will try to read them and fail with a weird
> error message, also they are bloat on the image syncing process that
> I'd rather do without)
>
Remove the files when moving from 32 <-> 64 bit. This is/was done automagically
several years now for the DB_INIT_CDB model. While the error message
may be "weird", it is in fact the error message that indicates that
you need to remove the __db* files.
> 2) if I can't stop them from being created, would I be able to look for
> some exit code path in the rpm source and just delete them there?
>
You don't want to delete the files because that _IS_ where the locks
are found. Removing the files introduces races (but is perfectly okay
if you are _SURE_ that nothing else is using an rpmdb at that moment,
which is often a pretty safe assumption).
> 3) what if a system has an rpmdb with those files and I revert the rpm
> db files (excluding those specific __db.00? files from the sync) so
> that the rpm db is now different form what it was when they were
> created.
> Does that create an inconsistency that could severly confuse RPM?
>
What happens if you do
cp /dev/zero /dev/mem
;-)
What is "the sync"? Are you using rsync to copy between machines?
Don't copy __db* files, they are useless on any other machine,
can only be used on the local machine. (Well one _CAN_ have
concurrent access through NFS+fcntl from multiple sufficiently
similar machines, but let's not go there ...)
There are failure modes if you screw around, typically DB_PAGE_NOTFOUND
when a page has gone AWOL in the cache. But rpm needs very little
from an rpmdb and deliberately has a KISS schema so that --rebuilddb
regenerates all the secondary indices, any time you want, and
the primary store of headers is both digest/signature checked, so
"inconsistency" is largely limited to dropping a registered package
that fails signature/digest/sanity checks during --rebuilddb.
Again, rpm-5.3 has full transactional protection and ACID properties,
so none of the above comments apply to rpm-5.3.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List rpm-users@rpm5.org
