I would prefer to maintain ACID transactional support, but I think my
hardware is just too limited.

Given the abandonment of support for sqlite3 in rpm5 I am inclined to try
to speed up writes to the SD card. In /usr/lib/rpm/macros, I activated
nofsync which sped things up significantly.

Previously, I attempted to tune /var/lib/rpm/DB_CONFIG, but I did not have
success with TXN_WRITE_NOSYNC. Do you (or does anyone else) have an example
for setting this flag in DB_CONFIG?

You suggested subbing out sync calls. Is that within rpmdb/db3.c? Would
that be better or more tunable than nofsync?

Jate


Jeffery Johnson wrote:

> > On Jan 12, 2016, at 11:25 AM, Jate Sujjavanich <jatedev@gmail.com> wrote:
> >
> > I am using rpm 5.4.9 as my package manager on an embedded system, and I am running into some bottlenecks with the Berkeley database. I am using an SD Card as my root file system.
> >
> > The rpm transactions from a kernel upgrade take an hour or so. Using the --stats option, I found that rpm was spending 15 or so seconds total per package in dbadd, dbget, etc. An strace revealed that many fsyncdata calls were happening. It appears this is due to ACID-ity of transactions.
> >
>
> Yes: fsync is especially costly on an SD card, and is measurably  slower
> on other media as well. ACID doesn’t come for free.
>
> A performance fix is usually to stub out sync (and all its variants) in the
> vectors used by Berkeley DB to make OS calls when opening the
> dbenv.
>
> > I found some posts saying that sqlite could be used as the database backend, so I tried this. I tried using configure to activate sqlite without success.
> >
>
> Those posts were from years ago: transactional support was added in ~2010.
>
> > I can compile with sqlite support, but so far, I can't get RPM to create any sqlite files. I've tried database conversion, initializing an empty RPM database, and setting _dbapi to 4 in /usr/lib/rpm/macros.
> >
>
> There are significant changes for transactional support that have not been implemented
> in the rpm sqlite3 code.
>
> > I discovered that within configure.ac <http://configure.ac/>, DBAPI is hard coded to 3 (Berkeley DB).
> >
>
> Yes.
>
> > I would like to know if sqlite3 as a backend is supported by RPM these days in 5.4.9 or any other versions. I want to find out if some of the patches within yocto/poky are breaking sqlite support.
> >
>
> The sqlite3 code (and support) in rpm5 was abandoned in favor of
> Berkeley DB ACID transactional support quite some years ago
>
> I don’t know what patches are in poky/yocto specifically, but it should not
> be too hard to find patches related to database functionality.
>
> Try filing a bug report with poky/yocto, which will likely trigger a support request to me.
>
> The performance on an SD card rather than the choice of backend database is
> the issue in need of fixing.
>
> hth
>
> 73 de Jeff
>
>
> > Jate
> >
>
>
>
>