Track proceessed input files to not re-process them when restarting about datatrove

[guipenedo]

Hi, I am not sure this would be trivial as you'd also have to recheck what was written to each output file/when the buffer was last flushed and this would potentially break some processing where you actually need to process the entire data when resuming a failed job (for example, when computing the signatures of a file for deduplication).
Can you give some more details on your particular slurm limitations? Is there a limit on the size of a job array, nb of jobs running simultaneously or the actual total number of jobs (including those waiting) on the cluster? One possible workaround would be to make each slurm job in the array run multiple datatrove tasks, this way you could still have many total tasks (and thus small amount of data per task - better resuming) without increasing the total slurm job amount

[marianna13]

Hey Guilherme,

Yes on my cluster I have a limit on how many jobs I can run in total therefore I encounter this issue while processing large datasets. How to make each slurm job datatrove to run multiple datatrove jobs? I tried specifying ntasks-per-node in sbatch args but I don't think it's a right logic (datatrove checks ARRAY slurm variables and doesn't care about number of tasks per node).

[guipenedo]

This option isn't present in the current code. I have added support for it here (untested): #153 let me know if it works for you/solves your problem

[marianna13]

Hey Guilherme,
I tried tasks_per_job=10 (i.e. 1 nodes with 10 parallel datatrove tasks) but it makes the whole thing very slow (way slower than 1 task per job). Is there any reason why it might be the case I mean yeah it's expected it should 10 times slower bc we allocate 10 less resorces per task but it's rather x100 slower)?

[shizhediao]

Hi, I am using tasks_per_job=10 but find the tasks are executed sequentially, which is too slow. I expect them to be finished parallelly.

Are there any suggestions? @guipenedo
Thanks!