On 2018-02-05 16:47, René J.V. Bertin wrote: > On Monday February 05 2018 15:34:52 Rainer Müller wrote: >> in your setup. To try this, you should be able to convert your registry >> database to this mode without making any changes to base itself. > > I presume that I can always keep a backup copy (= this affects only the > registry.db file)?
Exactly, it is only a setting in the SQLite file. You should be able to switch between the journal modes of WAL or DELETE with the sqlite command-line client without losing any data. > Can you remember how large the test registry was (or how many ports > installed, if that's more determinant)> On the main machine, I'm at approx. > 260Mb for the registry; on the test rig that's only 95Mb (24Mb compressed). > If the VACUUM does indeed do defragmentation by moving data to fill empty > space left after uninstalling this certainly explains what I'm seeing. That's > not "some disk activity", that's quite a bit of disk activity. For safe > defragging you first create a contiguous copy of a file/record, then compare > the copies, remove the old one, copy back the file to its new location and do > a 2nd verification before removing the temp. copy. It was only based on experience from developers. My main setup currently has a registry.db of about 180 MB, but this is still on Sierra with HFS+. While I have also seen same delays on exit, it never bothered me too much. > I think I've already seen discussions whether it's reasonably safe to disable > the sqlite journal on a filesystem like ZFS which already provides its own > comparable protection, and that the answer was probably no despite the > potentially costly redundancy. The SQLite journal is necessary to implement transactions (a sequence of SQL statements that allow a rollback in case of an error). So even when the backing storage of the database is guaranteed not to fail, it will always be necessary. >> However, you are not supposed to see VACUUM after read-only actions such >> as 'port work' or similar as it is guarded by a flag whether changes >> have been made. > > Indeed, I'm not. I'm seeing the vacuming effects when I do a `port work` or > similar AFTER a port uninstall. In the example I gave, I have to remember to > do the port uninstall after starting the fetch,checksum,extract,patch steps > if I do not want to waste time waiting to get control back. Hm, then it is probably not actually the VACUUM operation that causes the delay...? > It's not a huge deal, but having to wait a minute here, a minute there does > grow old, esp. if you just want to launch a lengthy upgrade operation and go > do something else in the meantime (and really esp. if that something else is > for some*one* else, like feeding the cats or doing the dishes ;) ) We could maybe keep a timestamp of the last vacuum run, so we only do this operation once per day. Of course that only helps if we are sure that it is the cause of the delay... Rainer