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 <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 > > > > > >
