On Thu, 2002-11-28 at 09:13, Stephen C. Tweedie wrote:
> In fact, it's not clear what we _can_ return as f_pos after the last
> dirent.
>
> We're only using 31-bit hashes right now. Trond, how will other NFS
> clients react if we return an NFS cookie 32-bits wide? We could
> easily use something like 0x80000000 as an f_pos to represent EOF in
> the Linux side of things, but will that cookie work if passed over the
> wire on NFSv2?
>
> The alternative is to hack in a special case so that (for example) we
> consider a major htree hash of 0x7fffffff to map to an f_pos of
> 0x7ffffffe and just consider that a possible collision, so that
> 0x7fffffff is a unique EOF for the htree tree walker.
Even if you fix this, there's another problem.
It seems that htree basically can't work with NFS in its current state -
it only works at all on small directories, which aren't hashed and
therefore use the non-htree cookie scheme. This can be fixed creating a
distinct EOF cookie.
However, in the transformation from a non-hashed to hashed directory the
cookie scheme completely changes, and in effect invalidates all cookies
currently known by clients. The obvious problem is that sometimes
adding a single entry to a directory will kill all concurrent readdirs.
I know that changing a directory while scanning it has at least some
undefined effects (allowed to miss entries, but not allowed to
duplicate, if I remember correctly), but if you add a single entry to a
directory, is it allowed to completely break any pending readdir
operation?
One solution I can think of is to always use name hashes as directory
cookies, even for non-hashed directories. This means that scans of a
small directory will require linear searching to find the entry
corresponding to a particular cookie, but since the directory is small
by definition it shouldn't be a bad performance hit.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 30 2002 - 22:00:21 EST