From: Andrew Bartlett <abartlet@samba.org>
To: Anand Avati <avati@redhat.com>
Cc: Eric Sandeen <sandeen@redhat.com>, Theodore Ts'o <tytso@mit.edu>,
ext4 development <linux-ext4@vger.kernel.org>,
Jan Kara <jack@suse.cz>, "J. Bruce Fields" <bfields@redhat.com>,
gluster-devel@nongnu.org, jra@samba.org
Subject: Re: [PATCH, RFC V3] ext3: add ioctl to force 32-bit hashes from indexed dirs
Date: Sat, 06 Apr 2013 10:05:25 +1100 [thread overview]
Message-ID: <1365203125.15177.33.camel@jesse> (raw)
In-Reply-To: <307C00EE-45DE-48A4-9FB7-3F164B51A524@redhat.com>
On Mon, 2013-04-01 at 13:34 -0700, Anand Avati wrote:
> On Apr 1, 2013, at 1:05 PM, Eric Sandeen <sandeen@redhat.com> 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?
Samba's use case fortunately is for DOS clients, and there just are not
very many of those any more (and tests that behave like dos clients,
which is how we noticed).
You CC'ed Jeremy, who is our authority on this area (I just noticed and
inquired into the failing tests). I'm hoping he can give a more
authoritative view on if we would push for this.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
next prev parent reply other threads:[~2013-04-05 23:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 16:25 [PATCH, RFC] ext3: add ioctl to force 32-bit hashes from indexed dirs Eric Sandeen
2013-03-28 20:40 ` [PATCH, RFC V2] " Eric Sandeen
2013-03-29 11:43 ` Jan Kara
2013-04-01 15:13 ` Eric Sandeen
2013-04-01 15:33 ` [PATCH, RFC V3] " Eric Sandeen
2013-04-01 18:17 ` Theodore Ts'o
2013-04-01 18:21 ` Eric Sandeen
2013-04-01 19:08 ` Theodore Ts'o
2013-04-01 19:49 ` Eric Sandeen
2013-04-01 20:00 ` Theodore Ts'o
2013-04-01 20:05 ` Eric Sandeen
2013-04-01 20:09 ` Theodore Ts'o
[not found] ` <5159E88F.8030704-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-04-01 20:34 ` Anand Avati
2013-04-05 23:05 ` Andrew Bartlett [this message]
2013-04-05 23:28 ` J. Bruce Fields
2013-04-05 23:26 ` Anand Avati
2013-04-08 9:28 ` Andrew Bartlett
2013-04-03 12:54 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1365203125.15177.33.camel@jesse \
--to=abartlet@samba.org \
--cc=avati@redhat.com \
--cc=bfields@redhat.com \
--cc=gluster-devel@nongnu.org \
--cc=jack@suse.cz \
--cc=jra@samba.org \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).