On Mon, Jan 20, 2014 at 12:39 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Sat, Jan 18, 2014 at 5:27 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>> On Sat, Jan 18, 2014 at 07:49:29AM +0100, Miklos Szeredi wrote:
>>> On Fri, Jan 17, 2014 at 11:08 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
>>> > On Fri, Jan 17, 2014 at 11:53:07PM +1300, Michael Kerrisk (man-pages) wrote:
>>> >> > The following additional errors are defined for renameat2():
>>> >> >
>>> >> > EOPNOTSUPP
>>> >> > The filesystem does not support a flag in flags
>>> >>
>>> >> This is not the usual error for an invalid bit flag. Please make it EINVAL.
>>> >
>>> > I agree that EINVAL makes sense for an invalid bit flag.
>>> >
>>> > But renameat2() can also fail when the caller passes a perfectly valid
>>> > flags field but the paths resolve to a filesystem that doesn't support
>>> > the RENAME_EXCHANGE operation. EOPNOTSUPP looks more appropriate in
>>> > that case.
>>>
>>> OTOH, from the app's perspective, it makes little difference whether a
>>> particular kernel doesn't support the reanameat2 syscall, or it
>>> doesn't support RENAME_FOO flag or if it does support RENAME_FOO but
>>> not in all filesystems. In all those cases it has to just fall back
>>> to something supported and it doesn't matter *why* it wasn't
>>> supported.
>>
>> Well, in theory it could allow an optimization:
>>
>> if (kernel_has_foo) {
>> ret = rename(.,.,.,.,RENAME_FOO);
>> if (ret && errno == EINVAL)
>> kernel_has_foo = 0;
>> }
>> if (!kernel_has_foo)
>> fallback...
>>
>> or maybe even:
>>
>> if (kernel_has_foo && fs_has_foo[fsid])
>> ret = rename(.,.,.,.,RENAME_FOO);
>> if (ret && errno == EINVAL)
>> kernel_has_foo = 0;
>> if (ret && errno == EOPNOTSUPP)
>> fs_has_foo[fsid] = 0;
>> }
>> if (!kernel_has_foo || !fs_has_foo[fsid])
>> fallback...
>>
>> which may both be of dubious value--unless, say, you're implementing a
>> network protocol and making this distinction to your client allows it to
>> save server round trips.
>>
>> That may not be *totally* farfetched--if for example we added rename2 to
>> the nfs protocol then servers probably will be required to make this
>> sort of distinction per filesystem, exactly to allow client logic like
>> the above.
>
> I understand, but that's a protocol issue, not a filesystem issue.
> The server will need to determine per-filesystem if the operation is
> supported or not, but that doesn't depend on the error value returned
> by the filesystem.
>
>> And as long as we can, I'd just rather give the caller more information
>> than less.
>>
>> As for precedent for EOPNOTSUPP: grepping through man-pages the one
>> documented use of EOPNOTSUPP I see for filesystems is fallocate, for a
>> similar "filesystem doesn't support this operation" case. "git grep
>> EOPNOTSUPP fs/" in the kernel repo suggests there are many more such,
>> but I haven't tried to figure out what any of them are.
>
> The reason I chose EOPNOTSUPP is because it has the specific meaning:
> "this operation is not supported, try to fall back to something else".
> EINVAL just means "something" is invalid. That would most likely be
> the "flags" argument in this specific case, and hence it works for
> renameat2().
>
> And differentiating between the "per-filesystem supported" and the
> "per kernel supported" thing based on the error value would also work.
> I don't really have a preference and I don't think it's a big deal.
>
> Michael?
I don't really have enough knowledge to know if EOPNOTSUPP would be
appropriate for "per-filesystem supported". I called the invalid
'flags' out, because EINVAL is the standard error for invalid flags.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
