https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INSTRM-145 Instrument control development <p>Hi Craig,</p> <p>With the previous version, data were written in /data/pfs/pfs, I don't remember why exactly (a link story or something like that).<br/> with new config writes directly in /data/pfs <br/> So what is the baseline ?</p> <p>an other effect is that the visit was reset</p> <p>We will wait until this is fix to take data (intensively I mean) </p> <p>Fabrice</p> INSTRM-145

New R1 writtes data in /data/pfs/ and visit was reset

Bug Normal Done Done cloomis fmadec Tue, 11 Jul 2017 08:09:22 +0000 Fri, 17 Mar 2023 21:20:48 +0000 Fri, 17 Mar 2023 21:20:48 +0000 ics_ccdActor 0 2 <p>we have a mount /data which has 2 folders, ait and pfs and I don't remember why there is an other pfs</p> <p>we should use /data/pfs but that means that we need to move the old pfs folder into this one</p> <p>I originally argued for saving images files to /data/pfs/YYYY-MM-DD/, but we might want to think about that for a second.</p> <p>This issue is <em>only</em> about how server(s) make data directories visible to the writing client, and what the data directories should be called. This is not about how the data from all the writers is made visible to readers, nor about how and where the server(s) manage and share data.</p> <p>In other words, given a $CLIENT (ccd_r1, hx_n3, mcs, ag_2, etc,), what name should the server(s) publish and what should the clients mount and write into?</p> <p>Given that it can be inconvenient to figure out server hostname and directory names, I would like to push the burden for that <em>entirely</em> onto the NFS and name servers: clients should be able to use generic names like <tt>pfsdata:/data/pfs</tt> and not need to know details as in <tt>idgserve:/exported/data42/</tt>. We can argue over what the generic name should be, but I'll start with, well, <tt>pfsdata:/data/pfs</tt>.</p> <p>In decreasing order of my preference. In all cases, the actors actually create and write into <tt>.../YYYY-MM-DD/</tt> or <tt>.../MJD/</tt></p> <div class='table-wrap'> <table class='confluenceTable'><tbody> <tr> <th class='confluenceTh'>scheme</th> <th class='confluenceTh'>server export</th> <th class='confluenceTh'>client mount</th> <th class='confluenceTh'>client write</th> <th class='confluenceTh'>notes</th> </tr> <tr> <td class='confluenceTd'>1</td> <td class='confluenceTd'>/data/pfs</td> <td class='confluenceTd'>/data/pfs</td> <td class='confluenceTd'>/data/pfs/ccd_r1/</td> <td class='confluenceTd'><tt>/etc/fstab</tt> is easy. Note that server is <em>not</em> required to make non-<tt>ccd_r1</tt> directories available, so not obvious that data can be endangered.</td> </tr> <tr> <td class='confluenceTd'>2</td> <td class='confluenceTd'>/data/pfs/ccd_r1</td> <td class='confluenceTd'>/data/pfs/ccd_r1</td> <td class='confluenceTd'>/data/pfs/ccd_r1</td> <td class='confluenceTd'>Every host has the same namespace. <em>Allows</em> mounting for multiple devices.</td> </tr> <tr> <td class='confluenceTd'>3</td> <td class='confluenceTd'>/data/pfs/ccd_r1</td> <td class='confluenceTd'>/data/pfs</td> <td class='confluenceTd'>/data/pfs/</td> <td class='confluenceTd'>Actor can completely ignore server details, but client system needs to fiddle <tt>/etc/fstab</tt></td> </tr> <tr> <td class='confluenceTd'>4</td> <td class='confluenceTd'>/data/pfs</td> <td class='confluenceTd'>/data/pfs/</td> <td class='confluenceTd'>/data/pfs</td> <td class='confluenceTd'>All actors write into same directory. What we are currently using.</td> </tr> </tbody></table> </div> <p>As far as the visit number goes, for non-Subaru sites this is mediated by a <tt>seqno</tt> file in the root of the client's directory: the one which contains the per-date directories.</p> <p>I don't really understand scheme 3...</p> <p>We could separate the different sources of data, but I will not say ccd_r1 but sps, hx_n3, mcs, ag_2</p> <p>all spectrograph data could stored in /data/pfs/sps that could be mount direclty as /data/pfs/sps or not</p> <p>I would tend to say that a high level separation of the data could be a good idea...<br/> But I do not have a strong opinion</p> <p>with the new bee install R1, data are back to /data/pfs/pfs !<br/> we should agree on something...</p> <p>I like 1 even more: it is hard for the system (/etc/fstab) to know the system's identity, but easy for programs (actors).</p> <p>For comment #12381 (2nd comment), please file new ticket to DAMD, and discuss there.</p> <p>was fixed.</p> Relates INSTRM-633 Development Rank 0|ii02fb: