On Mon, Dec 17, 2012 at 06:28:40PM -0500, Chris Mason wrote: > On Mon, Dec 17, 2012 at 04:09:07PM -0700, Zach Brown wrote: > > 1) The fundamental fix is to re-use deleted entry positions. Do we add > > another cache to index unlinked positions? Do we add an unreliable > > best-effort walk of the tree looking for holes in the key space? At the > > very least test index_cnt in unlink to get the basically useless > > index_cnt--? :) > > The index is dense enough that we can search for free spots without too > much pain. But, more below.
OK. Want me to take a stab at it? Is there a similar use somewhere I should work from? > > 2) Regardless of that, we have to deal with existing entry items with > > giant keys. If for no other reason than big jerks making corrupt images > > and leaving them on usb keys in Josef's driveway. Should we drop the > > silly INT_MAX setting for 64bit callers and return -EOVERFLOW for 32bit > > callers? (That'd be gross, but not unheard of. ext4 has grown htree > > behaviour that depends on compat detection: see its is_32bit_api() > > callers.) > > > > I can make up some fixes but I'd love to hear strong opinions first, if > > anyone's got 'em :). > > If we go past the 32 bit number we can use the hash offsets in readdir, > and just flag the directory as hashme-in-readdir Hmm. That sounds painful given either hash collisions or reconnecting nfs clients with previous f_pos values in use. With a dencent entry key allocator it sounds a lot cleaner to me to just admit that 32bit apps can't see more dirents than their f_pos can represent. It's already based on the number of entries rather than the bytes of entries so it'd be pretty hard to exhaust. Am I .. not right? :) - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
