Re: reading an empty directory after reboot is very slow
On 2015-04-23 11:22:11 -0500, David Wright wrote:
> Quoting Vincent Lefevre (vincent@vinc17.net):
> > On 2015-04-23 11:31:27 +0200, Nicolas George wrote:
> > > Le quartidi 4 floréal, an CCXXIII, Vincent Lefevre a écrit :
> > > > David's test shows that the renamed file is missed.
> > >
> > > No, it shows that the renamed file is NOT missed: he renamed the
> > > entry for inode 497003 from file2 into a long name, and that
> > > entry is returned, exactly once, under its old name. The "oops,
> > > file2 stat() fails" only shows the race condition between
> > > readdir() return and stat(); I am sure that if he printed
> > > dirent.d_ino instead of stat.st_ino, it would have printed
> > > 497003.
>
> Yes, it would. See below as to why I printed the stat() version.
>
> But actually, the answer is no. dirent.d_ino could fail as well.
> readdir is not thread-safe so the dirent could get clobbered between
> the call to readdir and printing it.
This doesn't matter here: the thread-safeness applies to a single
process with multiple threads. Here one considers a single-threaded
program. Note also that in a multi-threaded program, the full
readdir call is concerned by the lack of thread-safeness, not just
dirent.d_ino; said otherwise, you mustn't use concurrent readdir in
multiple threads (and readdir_r isn't a solution either since it can
yield a buffer overflow with arbitrary C libraries).
> > I only focused on the inode number and I thought that David's test was
> > printing dirent.d_ino (which was the obvious thing to do). Now, after
> > re-reading carefully what he said:
> >
> > "I scan the directory with readdir, then stat the file to obtain its
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > inode number."
> > ^^^^^^^^^^^^
> >
> > Indeed, this is the wrong way to do!
>
> Well, the program I filched, because filch it I did, printed more
> *interesting* stuff about the file, stuff like the size etc.
> I switched it to printing the (to most people, boring) inode number
> because, *for the purpose of this exercise*, the inode number acts as
> a unique identifier for a file which has just changed name.
Except that you don't show anything special: it is obvious that there
is a race condition on the filename when doing a file rename and
reading the directory containing that file at the same time, i.e. one
can either get the old filename or the new filename. This will be true
with *any* filesystem (I mean, the behavior is not specified).
> > So, there's a need for a new test.
>
> Feel free to write it.
No need, you have agreed above that the dirent.d_ino is correct
(except in case of programming error).
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: