[Btrfs-devel] btrfs and git-reflog

[Chris Mason]

On Friday 25 January 2008, Theodore Tso wrote:
> On Fri, Jan 25, 2008 at 12:47:45PM -0500, Chris Mason wrote:
> > 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.
>
> The problem comes with telldir/seekdir, and what to do with NFS
> support (I think v2 only allows a 32-bit seek pointer; I think IIRC
> it's fixed in the NFSv3 protocol, but the Linux NFS server uses the
> same interface point for both, so it doesn't help us).

Since btrfs maintains both a name index and an inode index, I can iterate over 
the name index (hash values) for use cases that require telldir/seekdir.  At 
any rate, there are a variety of choices for working around it, but I'm 
focusing on the disk format first ;)

-chris