[Btrfs-devel] btrfs and git-reflog

Jan Engelhardt jengelh at computergmbh.de
Fri Jan 25 10:07:58 PST 2008

On Jan 25 2008 12:47, Chris Mason wrote:
>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.

There was a debate about whether telldir/seekdir should continue to be
supported at the kernel level (http://lkml.org/lkml/2007/4/7/107)
btrfs could make an example by omitting it.

More information about the Btrfs-devel mailing list