registry.db-journal file location

[René J.V. Bertin]

Hi,

I have a test system on which certain operations, esp. uninstalling, block for up to over a minute after they appear to be done (= after the last debug info was printed). This doesn't just block the port command in question, it also blocks (almost?) any other port command I may execute, even those that probably don't need the registry like `port work`, `port clean` etc. I think this was a new "feature" that appeared somewhere in 2.4.99 .

There is disk activity during that period, I presume related to registry reorganisation, and yesterday I noticed a registry.db-journal file in the registry directory which was there and updated until the ongoing uninstall command finally exitted.

This particular system has MacPorts installed on a ZFS pool with lz4 compression and copies=2. I think this expensive operation could be sped up by using /tmp or $TMPDIR for the temporary registry file(s) - a change that should be transparent for regular users but potentially give a significant gain for more advanced set-ups where the temp directories are on much faster storage than that which holds the MacPorts prefix (or just a different drive).

I did a quick search for "journal" but the word doesn't appear to occur in the entire MacPorts src tree. Does that mean the use of temporary db/journal files is entirely internal to libsqlite3?

I've given some thought how I'd approach things if that were indeed the case. I know almost nothing about DB "manhandling", so mostly out of educational curiosity: would the following kind of approach work (make sense) for operations that change the registry?
1. set a write lock on the registry file (but still allow read operations)
2. clone the entire file to $reg_temp_dir/registry.new (using lowlevel block IO if possible)
3. apply the intended changes to the clone in $reg_temp_dir
4. move to registry.new in the registry dir
5. remove (unlink) the current registry, rename registry.new to registry.db
6. remote the write lock

I have a feeling that this could even speed up things a bit on my main system, where $prefix sits on a partition that has accumulated significant free-space fragmentation. I think this algorithm should also work when $reg_temp_dir is identical to the registry dir (skipping step 4 of course). I don't know what the penalty would be, but simple read operations should still be possible. It should (again?) become possible to 1) uninstall the old versions of a bunch of ports-to-be-upgraded and 2) fetch the sources for those ports and check the patches without having to wait for the uninstall. 

Thanks,
R.