[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: reading an empty directory after reboot is very slow

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.

> 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.

I guess if you only even scan directories to admire the interesting
numbers, then leave stat alone and enjoy the delicious delights of dirents!

> So, there's a need for a new test.

Feel free to write it.


Reply to: