On 18/01/16 20:59, Assaf Gordon wrote:
> On 01/18/2016 03:38 PM, Assaf Gordon wrote:
>> On 01/18/2016 03:31 PM, Assaf Gordon wrote:
>>> On 01/18/2016 02:27 PM, Pádraig Brady wrote:
>>>> On 18/01/16 18:18, Assaf Gordon wrote:
>>>>> FAIL: tests/cp/preserve-slink-time
>>>>
>>>> -2016-01-18 12:21:28.294123000 -0500
>>>> +2016-01-18 12:21:28.296528000 -0500
>>>>
>>>> cp -Pp didn't seem to preserve the timestamp on GPFS.
>>
>> This might be some weird bug in GPFS, not in CP.
>>
>> If I add a delay between the "ln -s" and "cp", then everything is fine.
>>
>
> previous example was needlessly complicated.
>
> Here's a more succinct example:
> ===
> $ for i in {1..5} ; do \
> ln -s nosuch$i d$i ; \
> cp -Pp d$i d$i-without-sleep ; \
> sleep 1 ; \
> cp -Pp d$i d$i-sleep ; \
> done ; \
> stat --format=%y,%n d*
>
> 2016-01-18 15:54:03.362745000 -0500,d1
> 2016-01-18 15:54:03.362745000 -0500,d1-sleep
> 2016-01-18 15:54:03.364136000 -0500,d1-without-sleep
> 2016-01-18 15:54:04.368773000 -0500,d2
> 2016-01-18 15:54:04.368773000 -0500,d2-sleep
> 2016-01-18 15:54:04.370309000 -0500,d2-without-sleep
> 2016-01-18 15:54:05.374139000 -0500,d3
> 2016-01-18 15:54:05.374139000 -0500,d3-sleep
> 2016-01-18 15:54:05.375543000 -0500,d3-without-sleep
> 2016-01-18 15:54:06.379171000 -0500,d4
> 2016-01-18 15:54:06.379171000 -0500,d4-sleep
> 2016-01-18 15:54:06.381534000 -0500,d4-without-sleep
> 2016-01-18 15:54:07.384989000 -0500,d5
> 2016-01-18 15:54:07.384989000 -0500,d5-sleep
> 2016-01-18 15:54:07.386153000 -0500,d5-without-sleep
> ===
>
> This is reproducible regardless of cp's version.
Seems like a cache coherency issue.
We can work around it with retry_delay_()
but it would be good to avoid.
Does a `sync d2` after the cp help?
