From: Eric Sandeen <sandeen@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: ext4 development <linux-ext4@vger.kernel.org>,
Anand Avati <avati@redhat.com>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH, RFC V3] ext3: add ioctl to force 32-bit hashes from indexed dirs
Date: Mon, 01 Apr 2013 15:05:35 -0500 [thread overview]
Message-ID: <5159E88F.8030704@redhat.com> (raw)
In-Reply-To: <20130401200052.GA24097@thunk.org>
On 4/1/13 3:00 PM, Theodore Ts'o wrote:
> On Mon, Apr 01, 2013 at 02:49:00PM -0500, Eric Sandeen wrote:
>>
>> Urgh, I guess if we are adding an interface which will live "forever,"
>> we may as well make it full featured & flexible, as long as the complexity
>> isn't out of hand, and I don't think it will be in this case. So I'm at
>> least half inclined to go ahead & allow toggling it on and off under the
>> right circumstances, even though it goes against what I think is my better
>> judgement. ;)
>
> If you want to have a fully flexible interface, then we probably
> should have a way to both get and set the flag. And from there the
> next step down the slippery slope would be to make this be a bit more
> like a fcntl-style F_GETFL/F_SETFL style interface, so we can in the
> future set and get other ext4-specific struct_file-specific flags. :-)
>
> I'll let you decide how far you want to go with this; I won't mind if
> you keep it with the original KISS interface, but I also won't mind if
> you want to create a somewhat more expansive interface.
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,
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."
I put it out mostly for review so it was ready if we needed it (since
certain quarters seem anxious) ;)
-Eric
> Cheers,
>
> - Ted
>
next prev parent reply other threads:[~2013-04-01 20:06 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 [this message]
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
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=5159E88F.8030704@redhat.com \
--to=sandeen@redhat.com \
--cc=avati@redhat.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--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).