[INSTRM-145] New R1 writtes data in /data/pfs/ and visit was reset Created: 11/Jul/17  Updated: 18/Mar/23  Resolved: 18/Mar/23

Status: Done
Project: Instrument control development
Component/s: ics_ccdActor
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: fmadec Assignee: cloomis
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to INSTRM-633 Define mountpoints and exports for im... Open

 Description   

Hi Craig,

With the previous version, data were written in /data/pfs/pfs, I don't remember why exactly (a link story or something like that).
with new config writes directly in /data/pfs
So what is the baseline ?

an other effect is that the visit was reset

We will wait until this is fix to take data (intensively I mean)

Fabrice



 Comments   
Comment by fmadec [ 11/Jul/17 ]

we have a mount /data which has 2 folders, ait and pfs and I don't remember why there is an other pfs

we should use /data/pfs but that means that we need to move the old pfs folder into this one

Comment by cloomis [ 12/Jul/17 ]

I originally argued for saving images files to /data/pfs/YYYY-MM-DD/, but we might want to think about that for a second.

This issue is only 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.

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?

Given that it can be inconvenient to figure out server hostname and directory names, I would like to push the burden for that entirely onto the NFS and name servers: clients should be able to use generic names like pfsdata:/data/pfs and not need to know details as in idgserve:/exported/data42/. We can argue over what the generic name should be, but I'll start with, well, pfsdata:/data/pfs.

In decreasing order of my preference. In all cases, the actors actually create and write into .../YYYY-MM-DD/ or .../MJD/

scheme server export client mount client write notes
1 /data/pfs /data/pfs /data/pfs/ccd_r1/ /etc/fstab is easy. Note that server is not required to make non-ccd_r1 directories available, so not obvious that data can be endangered.
2 /data/pfs/ccd_r1 /data/pfs/ccd_r1 /data/pfs/ccd_r1 Every host has the same namespace. Allows mounting for multiple devices.
3 /data/pfs/ccd_r1 /data/pfs /data/pfs/ Actor can completely ignore server details, but client system needs to fiddle /etc/fstab
4 /data/pfs /data/pfs/ /data/pfs All actors write into same directory. What we are currently using.

As far as the visit number goes, for non-Subaru sites this is mediated by a seqno file in the root of the client's directory: the one which contains the per-date directories.

Comment by fmadec [ 12/Jul/17 ]

I don't really understand scheme 3...

We could separate the different sources of data, but I will not say ccd_r1 but sps, hx_n3, mcs, ag_2

all spectrograph data could stored in /data/pfs/sps that could be mount direclty as /data/pfs/sps or not

I would tend to say that a high level separation of the data could be a good idea...
But I do not have a strong opinion

Comment by fmadec [ 18/Jul/17 ]

with the new bee install R1, data are back to /data/pfs/pfs !
we should agree on something...

Comment by cloomis [ 18/Jul/17 ]

I like 1 even more: it is hard for the system (/etc/fstab) to know the system's identity, but easy for programs (actors).

Comment by shimono [ 19/Jul/17 ]

For comment #12381 (2nd comment), please file new ticket to DAMD, and discuss there.

Comment by arnaud.lefur [ 18/Mar/23 ]

was fixed.

Generated at Sat Feb 10 16:22:00 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.