registry.db-journal file location

[Rainer Müller]

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