> On Jan 12, 2016, at 11:25 AM, Jate Sujjavanich <jate...@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
> 

Reply via email to