| Version 2 (modified by , 14 years ago) ( diff ) |
|---|
Minidvodb Copy Log
This is a log for the minidvodbcopy task (anything unusual).
2011-06-13
Heather restarted minidvodbcopy log. Steps:
minidvodb.copy.run.off minidvodb.copy.load.off add.minidvodb.copy ThreePi.V2 ipp0222 /data/ipp022.0/gpc1/mini-catdirs/ThreePi add.minidvodb.host ipp0222
This queued up all of the minidvodb_id's for ThreePi.V2. Normally, this is good. However, minidvodb_ids between 341 and 509 had already been copied to ipp022 before, since they are copies of (actually pointers to) the original ThreePi minidvodbs. Heather set those to a state of full.V1, since there already exists a copy of them on ipp022. Once they were set with a better state, Heather turned back on minidvodb.copy.run. The rsync seems to be working properly.
2012-02-17
Heather restarted minidvodbcopy. Same steps as above, but with
add.minidvodb.copy ThreePi.V3 ipp0222 /data/ipp022.0/gpc1/mini-catdirs/ThreePi add.minidvodb.host ipp0222
Additional hacks were needed to make it work - ippdvo does not have access to ipp022, except through the ssh keys for ipp. I added '-e "ssh -l ipp" ' to the rsync command and 'ssh ipp@ipp022' to the ssh command. I need to make this better, this is clearly a hack.
Additionally, I set 'alreadycopied' as the state for some of the ThreePi.V3 minidvodbs. I'm not entirely sure this was necessary, as those are located in the same directory, so rsync does nothing.
Also, we are running low on space on ipp022. We will probably run out, but the script is smart and will just fault them (with enough space so ipp022 is not cranky).
