Re: [Gluster-devel] [PATCH, RFC V3] ext3: add ioctl to force 32-bit hashes from indexed dirs

[Anand Avati]

On Apr 1, 2013, at 1:05 PM, Eric Sandeen <address@hidden> wrote:
> 
> Meh, let's just keep it simple then.  And I'd really like to know if
> gluster still even needs this, or if their new scheme will work instead,

As of this morning the new d_off transformation (Zach's idea) is merged in 
gluster. We had to put in some kind of ext4 awareness, and the "more complex" 
d_off transformation (which is finally working properly after fixing some minor 
issues) seemed better than calling ioctls by detecting the backend is ext4.

> in  which case we should drop it - but Samba made noise about needing it too,
> though I've not seen specifics, so I hate to merge it "just in case."

Yes, I too saw comments from Andrew Bartlett of the Samba team. It appeared to 
be the case that Samba could only present 32bit cookies while ext4 was now 
returning larger cookies (somewhat like the old NFSv2 clients problem?). This 
ioctl would be useful there I guess, bring it "in par" with knfsd's abilities 
of expressing desire for 32bit cookies? However, for knfsd legacy requirements, 
FMODE_32BITHASH is in generic VFS. But for a userspace file server, it would 
need to first gain the knowledge of which filesystems in the world actually 
present large cookies, and for the subset which support smaller cookies, issue 
filesystem specific ioctls() in their own specific ways.

Wouldn't it be "fair" to treat userspace file servers as equals, and provide a 
generic FS independent ioctl to set the common FMODE_32BITHASH flag on any dir 
fd? Think of it as a way of extending the "pointer access" to file->f_mode 
which NFS exercises, up to userspace?

> I put it out mostly for review so it was ready if we needed it (since
> certain quarters seem anxious) ;)

Appreciate your help Eric!

Avati