[Btrfs-devel] btrfs and git-reflog

[Chris Mason]

On Friday 25 January 2008, Theodore Tso wrote:
> On Fri, Jan 25, 2008 at 10:50:16AM -0500, Chris Mason wrote:
> > This happens because btrfs doesn't return the hash of the
> > file name as the offset to readdir.  It returns the inode number,
> > and since master is a new file, btrfs considers it a non-duplicate
> > entry.
>
> It returns the inode number?  How does it handle multiple hard links
> to the same file in a directory?
>
> Just curious....

For now this is handled like a hash collision, I end up with two directory 
entries at the same offset, which is allowed by the disk format but 
problematic if readdir runs out of room in the buffer and expects the next 
call to start over at the second name pointing to inode #N

If that happens today, I end up with a repeated dir entry coming out of 
readdir.  Longer term I'll add code so that it always picks up where it left 
off by allocating an extra readdir cookie for that file pointer.

Its ugly, but it won't happen often, and the seek benefits of readdir going in 
inode order are huge.

-chris