dvickernasa

Changed the subject since the root problem here is the time stamp info not being preserved. Here is a more comprehensive example. There is an odd mix of correct and...

That is possible. Here is the end of the output from the `dsync` run. ``` [2023-09-30T08:19:28] Syncing directory updates to disk. [2023-09-30T08:19:33] Sync completed in 4.942 seconds. [2023-09-30T08:19:33] Started: Sep-29-2023,16:34:18...

Actually, the data I copied was done with two separate `dsync` runs since they were in two different areas. I've attached the output from both runs. The `ccdev` run showed...

I've been doing some tests this afternoon using a smaller dataset. Basically did this: * dsync /src /dest * cd /dest ; lfs find . | xargs touch * dsync...

> How many nodes and processes are you using? I'm using 16 cores on a single workstation for these transfers. > Does it do a better job at setting timestamps...

> Regarding all of those deletes, I think that second dsync detected the mismatch in mtime between the source and destination files. It then assumes the files are different, it...

Sorry, I know this isn't directly related to this issue, but I have a question about `dsync`'s behavior. Here is an example of the end of a transfer. ``` [2023-10-03T19:32:44]...

I've got a few more datapoints on setting the times. First of all, the rsync verification of our 141 TB, 2.7M files dataset is still going. Its been running since...

Correct - single node and lustre to lustre.

Sorry, to answer your questions about errors, Yes, there were some errors. They did a couple intermediate transfers while the datasets were in use and being modified in an effort...