On Thu, Aug 28, 2008 at 04:23:48PM -0600, Andreas Dilger wrote: > > For small directories which could potentially get converted into htree > > format, we already sucking the entire directory and putting it into an > > rbtree. We could just do this for all directories less than or equal > > to 32k, but have them returned sorted by inode instead of by hash > > value. At least on my laptop, this accounts for 99.93% of the > > directories on my root filesystem. > > What happens if the directory is grown at that point? I thought the > reason for keeping it sorted in hash order was to deal with the > telldir headache? I guess if the whole thing is in memory then it > can be attached to the fd and discarded once read or seeked-on > (and POSIX doesn't require reporting new entries after the start > of the read). It's fine, because according to POSIX it's undefined what happens to files that are created or deleted after the last opendir() or rewindir(). So basically, the b-tree is attached to the opendir, and we discard it and re-create it if we ever seek to the beginning of the directory. This logic is already in the kernel, since it's exactly the same situation if the file is grown past the point where it becomes an HTREE directory. > Doing this at the VFS level would also benefit _most_ filesystems, > though maybe not ones like XFS or btrfs that have their own preferred > order. Possibly, but it's a lot easier inside ext3/ext4 because we have most of the machinery in place and in use already. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
