On Sunday April 15, [EMAIL PROTECTED] wrote: > On Thu, Apr 12, 2007 at 10:35:49AM -0700, H. Peter Anvin wrote: > > > > Any fixed size is too small. It should be a dynamic size. > > Idally it should be dynamic, but my guess is that if the cookie were a > fixed 256 bits, it would be sufficient for pretty much all filesystems. >
"my guess", "pretty much" really bother me. It sounds like "The largest anyone has asked for is 128bits, or let's double it and hope that is enough until the next protocol revision". Which was probably reasonable when NFSv2 was being developed and maybe even when v3 was developed, but I kind of hoped we were beyond that. If a filesystem wanted to order filenames lexically, it really needs 256 *bytes*. And it is fairly silly having a cookie that big. I still thinking that filename + 64bits is required and plenty (aka necessary and sufficient). You would need a truly enormous directory before that would be insufficient for an off-set based scheme or a hash-plus-collision scheme, and it is clearly enough for a lexically-ordered scheme. I wouldn't argue against 128bits (64 for a search key and 64 to guarantee uniqueness) but I really think 256 excessive with no value. We we still need the last-filename in the READDIR key. (Mind you, I'm still wondering why NFSv4 felt the need for 128 *byte* file handles so maybe I'm just small minded :-) NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
