• Main INDEX
  • Monthly INDEX
  • PREV
  • NEXT
    Make New Entry, Make Followup Entry

    User name R. Michaels

    Log entry time 17:00:29 on December13,2011

    Entry number 359817

    This entry is a followup to: 359744

    Followups:

    keyword=duplicate data files

    The following are duplicated data files affecting two runs,
    1152 and 1162. Presumably there was a problem with CODA
    whereby the run number did not increment. They are most
    likely junk. Despite that, we have a policy to never erase
    a data file. So I have renamed them to give unique names,
    so they will go to the MSS tape silo.

    Run 1152. The 1st one in MSS has 786432 bytes.
    The duplicates are as follows. (Bytes, creation time, filename)
    65536 Sep 20 11:05 /adaql2/data1/g2p_1152_2nd.dat.0
    4259840 Sep 20 11:44 /adaql2/data2/g2p_1152_3rd.dat.0
    40173568 Sep 20 12:01 /adaql2/data3/g2p_1152_4th.dat.0
    98304 Sep 20 10:55 /adaql2/data4/g2p_1152_5th.dat.0

    Run 1162. MSS has 8617984 bytes.
    Duplicates:
    8617984 Sep 22 10:29 /adaql2/data2/g2p_1162_2nd.dat.0
    32768 Oct 20 12:01 /adaql2/data3/g2p_1162_3rd.dat.0

    ------------------------------------

    The experiment is advised to WATCH OUT for the run number
    not incrementing in the filename. We've seen this before
    with this new version of CODA. The solution (workaround) is
    to do a "startcoda". Somehow, that forces CODA back into
    synch. I think (but I'm not sure) the database that controls
    the GUI gets out of synch with respect to the database that
    is consulted to get the run number for the datafile. It would
    be nice to fix it. The risk is that you have multiple files
    with the same run number or that you overwrite data. I suggest
    to ask the shift crews to write down in their paper logbook the
    run number observed in the filename on disk (or do a checkmark
    to force them to verify this for each run). If it's bad, they
    should immediately do a "startcoda".