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. _______________________________________________ Btrfs-devel mailing list [email protected] http://oss.oracle.com/mailman/listinfo/btrfs-devel
