On 7/26/19 9:29 AM, Armin Noll wrote:
The below email is classified: Internal
It looks like classifications and disclaimers like this and at the end of your
original
email are unenforcable on a public mailing list like this one. I recommend to
use
an email account which does not automatically add such pointless claims.
Hello,
we use findutils version 4.4.2 on Red Hat Enterprise Linux 6.9.
Executing the following call to find
/usr/bin/find /data/sysprog/095/reports -maxdepth 1 -type f -regextype posix-egrep -regex
"/data/sysprog/095/reports/95RPTAB001EUREX20190717[0-9]{8}_XETCASH.*[.]DAT"
results in following error message:
/usr/bin/find:
`/data/sysprog/095/reports/01RPTTT127EUREX2019071720190717.XML.inc': No such
file or directory
The mentioned file
/data/sysprog/095/reports/01RPTTT127EUREX2019071720190717.XML.inc
has been created in parallel by another process and has then be renamed
afterwards to
/data/sysprog/095/reports/01RPTTT127EUREX2019071720190717.XML
This is exactly the analysis of what happened. find(1) is supposed to report
this error ... and this is why the -ignore_readdir_race option exists.
It's worth mentioning that we have an open bug report for that option
saying it's not working in some certain circumstances, but in the common
case it should work quite well.
According to log output we have, the find takes ca. 9 seconds before it reports
the shown error message and terminates.
I assume you have many thousands of files in that directory, right?
Some (or many) file systems become pretty slow when there are more
than 100.000 or even a million files in one directory, or when the
file system is remote (like nfs or sshfs). There's probably not much
that find(1) can do about it. You could run it via strace with
timing (-tt) to find out where the time is being spent, but I guess
it is in the syscalls.
This has been observed just once.
We tried to reproduce this but were not successful.
This happens quite more often with more volatile file systems like /proc.
How can this be explained?
You did. :-)
Is this maybe a bug?
Not as long as you run it without -ignore_readdir_race.
Have a nice day,
Berny
