[Btrfs-devel] btrfs and git-reflog
chris.mason at oracle.com
Fri Jan 25 09:47:45 PST 2008
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.
More information about the Btrfs-devel