Race Condition with hard links on 7.4.2 ?

[Michael Krause]

Hello,

we stumbled upon what appears to be a bug in the hard link implementation of BeeGFS:

Example:

# Create a hard link
echo "42" > t_file
ln t_file t_link

# parallel read on different nodes(!)

Variant 1 with SSH:

for i in {1..3}; do \
ssh node-$i 'for i in {1..1000}; do cat t_link >/dev/null &
done

Variant 2 with mpirun

salloc -N3 mpirun bash -c "for i in {1..1000} ; do cat t_link >/dev/null ; done"


Output: (some of the 3k reads failed with ENONT)

[31] 3177531
[32] 3177532
[33] 3177533
cat: t_link: No such file or directory
cat: t_link: No such file or directory
cat: t_link: No such file or directory
cat: t_link: No such file or directory
cat: t_link: No such file or directory


My questions:

Is this a known bug/limitation?

Is it related to the new implementation supporting cross-directory hard links?

And is it possibly fixed in 7.4.3, already? Release notes mention some race.


cheers
Michael Krause
--
MPI for Human Development
Room: 42 # Tel: -471

[Guan Xin]

Hi,

Probably something equivalent to the NFS option "lookupcache=positive" would help.

So this looks like a feature request?

Guan

[Michael Krause]

Hello Guan,

> Probably something equivalent to the NFS option "lookupcache=positive"

Can you elaborate? I don't see how this is a caching issue. All I do is
read from an existing file (hard link), which is never updated.

cheers
Michael

> --
> You received this message because you are subscribed to the Google
> Groups "beegfs-user" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fhgfs-user+...@googlegroups.com
> <mailto:fhgfs-user+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/fhgfs-user/cd2ae349-25ad-4d65-8b01-b78fff645a54n%40googlegroups.com <https://groups.google.com/d/msgid/fhgfs-user/cd2ae349-25ad-4d65-8b01-b78fff645a54n%40googlegroups.com?utm_medium=email&utm_source=footer>.