Re: reading an empty directory after reboot is very slow
Quoting Vincent Lefevre (vincent@vinc17.net):
> On 2015-04-20 13:04:41 -0500, David Wright wrote:
> > Quoting Vincent Lefevre (vincent@vinc17.net):
> > > But with the current solution (no automatic moving of an entry), you
> > > can't miss an entry that hasn't been removed.
[...]
> > ...so if you happen to be reading the entry for file5 at the
> > time I typed mv, you'll get the entry for file4 twice, under
> > two different names. (Or the opposite.)
>
> OK, so, if the rename(2) system call can reorder the entries (this is
> not quite clear because one doesn't see the empty entries here),
No, and you wouldn't *normally* see them with readdir, I'd suppose.
> then
> there is already a problem with the file system. Getting an entry
> twice under different names is not much a problem, IMHO, because one
> can look at the inode number; there's a race condition, but at worst,
> one can just miss a *new* inode (whose number has been reassigned).
> Missing an existing entry is a problem.
...easily demonstrated with
~ $ for j in 1 2 3 4 5 6 ; do mkdir /tmp/testdir/file$j ; done
~ $ ls -lU /tmp/testdir
total 24
drwxr-x--- 2 david david 4096 Apr 21 10:58 file1
drwxr-x--- 2 david david 4096 Apr 21 10:58 file4
drwxr-x--- 2 david david 4096 Apr 21 10:58 file5
drwxr-x--- 2 david david 4096 Apr 21 10:58 file6
drwxr-x--- 2 david david 4096 Apr 21 10:58 file2
drwxr-x--- 2 david david 4096 Apr 21 10:58 file3
~ $ mv -i /tmp/testdir/file3 /tmp/testdir/file3file3file3file3file3file3file3file3file3file3file3file3file3
~ $ ls -lU /tmp/testdir
total 24
drwxr-x--- 2 david david 4096 Apr 21 10:58 file1
drwxr-x--- 2 david david 4096 Apr 21 10:58 file4
drwxr-x--- 2 david david 4096 Apr 21 10:58 file5
drwxr-x--- 2 david david 4096 Apr 21 10:58 file3file3file3file3file3file3file3file3file3file3file3file3file3
drwxr-x--- 2 david david 4096 Apr 21 10:58 file6
drwxr-x--- 2 david david 4096 Apr 21 10:58 file2
~ $
where file3 goes AWOL.
> What do the backup systems do?
I don't know. Lock the directory and slurp it (if it's not too big),
otherwise check the modification time before and after reading it,
and reread it if necessary, maybe...
Cheers,
David.
Reply to: