Re: reading an empty directory after reboot is very slow
Quoting Vincent Lefevre (vincent@vinc17.net):
> On 2015-04-22 23:06:47 -0500, David Wright wrote:
> > Quoting Vincent Lefevre (vincent@vinc17.net):
> > > On 2015-04-21 11:05:58 -0500, David Wright wrote:
> > > > 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.
> > >
> > > But this matters for the implementation in the kernel.
> >
> > What's "this". And what does it matter? You make some system calls,
> > and you get replies. They come out of a black box.
>
> I mean: to know what is done internally in order to prove that there
> is a problem. Otherwise you need to provide a test based on readdir,
> not on the "ls -lU ..." output, which contains incomplete information
> (because the kernel has more information, which could be used by the
> implementation of readdir).
>
> [...]
> > So you don't believe the problem when it's demonstrated,
>
> What I'm saying is that you haven't demonstrating anything: you showed
> some "ls -lU ..." output, but did not say what was done internally by
> the kernel. So, the readdir test as you have now done below was
> necessary.
Well, I'm assuming that ls -U is honest, and it really doesn't shuffle
the order that it receives from the filesystem.
> > Ask yourself why an efficient filesystem would move a load of
> > directory entries just because someone renamed a file.
>
> First I wonder why such an efficient filesystem moves a directory
> entry while this is not needed. With your example:
It is needed. With the naive directory structure (a simple list), you
can't put a long string where a short string was.
> So, the kernel is doing non-trivial things.
[test snipped]
> Thanks for this test. I have two remarks:
>
> 1. I'm wondering why the kernel moves a renamed directory entry instead
> of just modifying it. For easier recovery in case of serious problem
> (hardware failure, kernel crash...)?
[hashing snipped]
> Do you know why it is doing this? To retrieve a file faster via the
> hash, by starting at the "right" place instead of the beginning of
> the directory?
You answered it yourself.
> I suppose that this would work well only when there
> is only one block (small directories), otherwise things get messed
> up after that.
I think they do better than that!
Cheers,
David.
Reply to: