Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

In-allocation runs: whole-second mtimes on Lustre products_dir trigger Snakemake clock-skew failures

Đang mở
  • Có gì không ổn?
#971 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
backend, infrastructure

Hướng nghiên cứu

Start by tracing how sp --in-allocation chooses products_dir and how exp_persist and other persistence rules declare outputs; the issue names no file paths or tests. Compare the two proposed fixes, using #953 as a reference for node-local storage and persistence. Done means a chosen workflow change prevents Lustre mtime clock-skew failures while publishing correct products.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Snakemake rejects outputs written to a filesystem with whole-second mtimes when their inputs are on a filesystem with nanosecond mtimes.
This affects single-allocation runs (sp ... --in-allocation) whose outputs.products_dir is on Lustre while the work directory is on node-local NVMe.

On the Alliance cluster Fir, /scratch is Lustre and stores mtimes to the second (stat shows .000000000), while $SLURM_TMPDIR stores nanoseconds.
When a rule reads an input from the work directory and writes its output into products_dir within the same second, the output's truncated mtime is earlier than the input's.
Snakemake then raises its "older modification time … clock skew" WorkflowError, deletes the output and retries the job.

  • In the first five Fir production batches (25 tiles each, code 61b6255f), this happened 14–55 times per batch, mostly in exp_persist.
  • Retries usually land in a later second, so most batches finish, and their products are correct: the PSF models and exposure maps of 19 exposures processed on both Fir and Nibi are byte-identical.
  • One batch ran out of retries on two exp_persist jobs and failed.
  • On Nibi, /project and /scratch are NFS with nanosecond mtimes, and the error does not occur in any of ~480 batch logs.

Workaround used on Fir: set products_dir on node-local disk for the whole run, then copy the finished tree to shared storage once at the end.

Possible fixes in the workflow:

  1. sp --in-allocation keeps products in the work directory and publishes the finished tree to products_dir as a final step. This is the Fir workaround made the default, and it also gives a single point where the published tree is complete.
  2. The persisting rules (exp_persist and the other rules that copy into products_dir) declare their products outside Snakemake's output set, so the mtime check never compares across filesystems.

Option 1 seems simpler to me, and it matches how #953 already keeps exposure stores node-local and persists only the per-exposure products.
Any Lustre-backed cluster (Fir, Narval, Rorqual, and possibly others) will hit this as soon as production moves there.

— Claude (Opus 5.5) on behalf of Cail

Ngôn ngữ chính
Python
Star
18
Fork
14
Merge trung bình
4 ngày 14 giờ
Pull request đã merge (30 ngày)
44

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CosmoStat/shapepipe

Tất cả issue của CosmoStat/shapepipe

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.