Quoting Vincent Lefevre (vinc...@vinc17.net): > On 2015-04-22 23:06:47 -0500, David Wright wrote: > > Quoting Vincent Lefevre (vinc...@vinc17.net): > > > On 2015-04-21 11:05:58 -0500, David Wright wrote: > > > > Quoting Vincent Lefevre (vinc...@vinc17.net): > > > > > On 2015-04-20 13:04:41 -0500, David Wright wrote: > > > > > > Quoting Vincent Lefevre (vinc...@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. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150423163903.GD8639@alum