Re: Bugs / Patch in nfsd

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Nov 18, 2013 at 09:23:15AM -0800, Christoph Hellwig wrote:
> On Mon, Nov 18, 2013 at 12:01:32PM -0500, J. Bruce Fields wrote:
> > Just tracing a v3 mount I can confirm that S_IFDIR (0x4000, 040000)
> > gets set in GETATTR replies.
> 
> Oh. got it.  We set the stat file type, nothing related to the 32-bit
> readdir cookie.
> 
> > Anyway, absent objections my default is to queue this up for 3.14 (using
> > S_IALLUGO).
> 
> Yeah, that part looks good to me.  But it seem Albert still has an issue
> with the directory offsets.  Might be worth to get the ext4 developes
> in the loop for that, as I doubt it's an issue with the nfsd code.

One problem he's seeing was RHEL5-specific, the other is the known ext4
problem that's been discussed before.

(Basically, ext4 has a tradeoff between correctness, lookup performance,
and compatibility with some buggy old clients:

	1. turn off dir_index and performance on large directories may
	   suffer, but it's correct and any client will be happy.
	2. turn on dir_index and return 32-bit cookies: now you get
	   directory loops on large directories due to random hash
	   collisions.
	3. turn on dir_index and return 64-bit cookies: some clients seem
	   to then return errors to 32-bit applications doing readdirs.
	   Cookies have been 64-bit since NFSv3 and 32-bit Linux clients
	   deal with this fine (it fakes up its own small integer offsets
	   to return to applications), but apparently some other clients
	   return errors on readdir.

So currently we default to 3 and if people complain, tell them to turn
off dir_index and complain to their client vendor....)

--b.