|
From: SourceForge.net <no...@so...> - 2008-11-18 23:23:59
|
Bugs item #2012046, was opened at 2008-07-07 09:12 Message generated for change (Comment added) made by straten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=992842&aid=2012046&group_id=205239 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Data Acquisition Group: None >Status: Closed >Resolution: Fixed Priority: 9 Private: No Submitted By: Willem van Straten (straten) >Assigned to: Andrew Jameson (ajameson) Summary: two dada_dbdisks running Initial Comment: It looks like two copies of dada_dbdisk are running at the same time. All of the machines are red-lining machine load and filling the data block. I am guessing that at some point the disk writing efficiency was low and data spilled over to the back up data block. ---------------------------------------------------------------------- >Comment By: Willem van Straten (straten) Date: 2008-11-19 10:23 Message: Andrew has fix this: if dbdisk is the read client, then the backup buffer is dbnull. That is, if not keeping up with writing to disk, the data are pitched. ---------------------------------------------------------------------- Comment By: Andrew Jameson (ajameson) Date: 2008-07-07 15:16 Message: Logged In: YES user_id=893682 Originator: NO Not sure why dada_dbdisk could not keep up... However the client_observation_manager should now launch dada_dbNdb with only -k eada (not -k eada -k fada) so the data should never get to the secondary data block... This fix does preclude us from using other auxiliary nodes, however I dont imagine that we would want auxiliary nodes when using dbdisk.scratch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=992842&aid=2012046&group_id=205239 |