Re: [Sks-devel] Your thoughts and any objective performance data

[Kim Minh Kaplan]

Jeremy T. Bouse wrote:
> The issue is the systems have 20GB drives and the sks database
> is 13GB. This presents the problem of I can't download a keydump, import
> it and delete it.
[…]
>     So my question is does anyone have any thoughts on how best to
> handle?

Without modifying sks you could do the import on another machine and then transfer the database DB directory.

Would adding an option to sks build to import dump files one at a time help? You could then import the first file, delete it and so on. Or an option to unlink each file once it is read? I'm asking this because I think it would be trivial do add one of these options.

> I've simply imported the keys and removed the dump in the past
> as I assumed that was faster than having it read the keys from the dump
> files themselves. Am I correct?

While I assume the same this is not backed by any solid facts nor measurements. In any case the speed difference is most probably insignificant.

> Is it worth trying to maintain importing
> over fastbuild?

Given your current options (i.e. build the DB on another machine or over NFS) I would prefer fastbuild for ease of operations.

The main reason I prefer build over fastbuild is that over time, as keys are updated, the original dump will contain more and more dead data. This result in lost disk space. Once again I have not measured the actual space loss.

Kim Minh.