On Sat, Apr 06, 2013 at 10:05:25AM +1100, Andrew Bartlett wrote: > On Mon, 2013-04-01 at 13:34 -0700, Anand Avati wrote: > > On Apr 1, 2013, at 1:05 PM, Eric Sandeen <sandeen@xxxxxxxxxx> 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? > > If 32-bit cookies are baked into current-generation NFS, even if Samba > doesn't take this up, wouldn't > http://sourceforge.net/apps/trac/nfs-ganesha/ need it just the same? I guess ganesha could use tricks similar to gluster's and throw out the low bits of 64-bit cookies. For knfsd I've been telling people they should either - fix their clients (the protocol *does* define cookies to be 64 bits, and the Linux client has shown it's practical to remap 64-bit cookies to 32-bit cookies if necessary for applications using 32-bit interfaces), or - fix applications to use 64-bit interfaces, or - just turn off dir_index: hopefully the fact that they've been happily using ext4 without seeing hash collisions means they aren't using very large directories, hence can live without dir_index. knfsd is still returning 32-bit cookies to v2 clients (that's the protocol), but I doubt v2 support is very critical for Ganesha. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
