[Bug libc/23960] [2.28 Regression]: New getdents{64} implementation breaks qemu-user

["fweimer at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23960

--- Comment #66 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Danny Milosavljevic from comment #62)
> (In reply to Florian Weimer from comment #60)
> > (In reply to Danny Milosavljevic from comment #59)
> > > It's impossible to store a 64 bit result into a 32 bit slot.
> > 
> > You can do something like that if you can maintain a translation table.
> 
> Mathematically speaking, no, you can't.  There cannot be a 1:1 mapping
> between all 64 bit values and all 32 bit values.
> 
> I know what you mean--in practice it could be good enough, if the directory
> doesn't have too many entries (or, depending on implementation, telldir
> isn't called too often--though first that implementation with only telldir
> doing the counting has to be possible.  Is it?).
> 
> But that's just kicking the can down the road--eventually, someone somewhere
> will have that many entries.  And then, the mapping will fail.

Most Linux file systems use some hash-based approach, so that they do not have
to maintain a separate lookup table for seeking in directories. A simple offset
does not work because there are POSIX (and quality-of-implementation)
requirements that after seekdir, the same sequence of entries is produced even
if unrelated directory entries are created and removed. Because of the hashing
involved, directories with tens of millions of entries may run into problems
even with a 64-bit hash.

If a file system uses a separate data structure for directory seeking, it won't
have a problem to generate 30-bit offsets, in which case glibc could avoid
translation completely (if it reserves the offsets in the range INT_MAX/2 + 1 …
INT_MAX for translation, which should be large enough).

-- 
You are receiving this mail because:
You are on the CC list for the bug.