[Btrfs-devel] btrfs and git-reflog
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