Btree directories (Re: Status of HFS+ support)

[flar at allandria.com]

Matthew Wilcox wrote:
> You can lock while you're in a call, but eventually, you fill up the
> user's buffer and return.  At that point, you have to drop the lock
> because they might never call you again.  So you have to consider
> the case of a file being added or removed between calls to getdents.
> Current HFS doesn't even pretend to try.  It just stores an index (0
> .. n-1) and you pick up from there.  So sometimes you get files twice,
> sometimes files don't show up at all.
>
> I suspect you need to store the key of the item you just found, and
> then continue filling in the buffer from there on subsequent calls.
> The trouble is that there frequently isn't enough space available to
> do that.  The proposed ext2 btree extensins needed 64 bits of space and
> there was only 32 bits available.  What size keys does HFS+ have?

Catalog keys in HFS+ can be anywhere from 8 bytes all the way up to
518 bytes. I actually do save the key and do a search in the btree
in my HFS+ module. (It doesn't seem to work however. And yes, I'm
helping out Klaus with his code as well as working on a kernel
module with completely separate code.)

> Hmmm.. now the LFS patches have gone in and f_pos is now a 64-bit quantity,
> this sounds more plausible.  I'd be curious to hear from the ReiserFS
> people how they solved this problem.

The support for 64 bit filesystems is important for HFS+ as well, since
it uses 64 bit file sizes for all files.

> > I'd really like to know how the concurrency of the kernel filesystem
> > should work, can anybody feed me with documentations about that ?
>
> I've cc'd linux-fsdevel, where people can fill you in.

I've been ignoring this issue, but I certainly would love pointers to
more documentation.

	Brad Boyer
	flar at pants.nu


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/