[Samba] [lustre-discuss] Odd "File exists" behavior when copy-pasting many files to an SMB exported Lustre FS

[Jeremy Allison]

On Thu, Sep 22, 2022 at 09:21:42AM +0000, Michael Weiser wrote:
>
>I had a first impelementation of that attached to my first mail. Did that get through? In my case it was enough to mask lustre.lov in flistxattr and fgetxattr so that clients never get to see it and fsetxattr is never attempted.

No, I didn't see any code.

>What's bugging me about this approach as well as the xattr.conf
> workaround is that the error behaviour on the client side is so
> very unintuitive. How will we get people to correlate some
> "file already exists" error with peculiar extended attributes
> behaviour of their file system so they become aware they need
> to configure a workaround? It'd certainly be nice if we could
> find a way for samba to "just do the right thing"[tm].

Well in this case Lustre is acting as a malicious filesystem :-).
Inventing EA's in this manner isn't something Samba is written
to protect itself against. We expect sane filesystem behavior :-).

>The attributes using a non-existant namespace (lustre.*) doesn't seem exactly right[tm] to me either. And it would wreak havoc if samba were actually able to set the canonicalised user.lustre.lov attribute when copying it back, duplicating and likely somewhat non-deterministically overwriting it later.
>
>But more crucially, what seems problematic here is that Lustre supports
> listing and reading extended attributes for unprivileged users but does
> not allow setting them and returns ENOTSUP rather than EPERM or
> something else at that.

That's a breaking of the Linux EA API contact. Don't do that.

> So samba would need to take into account that not all filesystems
> support extended attributes as a whole but might support some
> operations on them but not others.

No, that way lies insanity and unmaintainable complexity in
Samba. Blame POSIX (again) for not standarizing EA behavior.

If you have custom filesystem EA behavior the correct fix
is to write a Samba VFS module to expose only expected
behavior to the calling fileserver code.

It's what we do for every other filesystem and Lustre
just needs to do the same.

>I'm with Bjoern that there likely are or will be other
>filesystems with peculiar extended attribute behaviour.

Samba VFS modules. The only maintainable solution.

>What might be the possible fallout from removing the created
>file in the error code path? Shouldn't it be safe with proper
> locking in place as it appears to be?
>Wouldn't a best-effort cleanup in the error path be better
>than leaving a known-to-be-incorrect state behind?

When we have vfs_lustre, setting these EA's will silently
strip them off and not fail, so we don't have to change the
error code path.

Please fix your mailer to wrap at 80 columns. Reformating
your emails to reply is exhausting :-).