You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For HK, specifically, we're sort of aiming for ~1GB files, but without crossing ctime % 100000 boundaries. So it might be good if aggregator had a mode where it could change files based on a variety of conditions; e.g. if any of:
file size reaches some threshold
some time has passed (current implementation)
some ctime boundary (e.g. ctime % 100000 == 0) is crossed.
The text was updated successfully, but these errors were encountered:
What requirement is the ctime boundary coming from here? I've always thought that this boundary was soft and it was ok for files to go over. Is this just to make sure small files are eventually written within a day?
What requirement is the ctime boundary coming from here? I've always thought that this boundary was soft and it was ok for files to go over. Is this just to make sure small files are eventually written within a day?
What requirement is the ctime boundary coming from here? I've always thought that this boundary was soft and it was ok for files to go over. Is this just to make sure small files are eventually written within a day?
Yes, it definitely help in making sure small files are eventually flushed. If you're going to do that, it makes sense to do it on the ctime5 boundaries because a lot of our data organization is by ctime5. For example, HK books can be finalized and archived if we make a point of finalizing data files around ctime5 boundaries.
Originally from https://github.com/simonsobs/ocs-deployment-configs/issues/172.
The text was updated successfully, but these errors were encountered: