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