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

On Fri, Sep 23, 2022 at 10:22:38PM +0200, Daniel Kobras
wrote:
>Hi Jeremy!
>
>Am 23.09.22 um 18:42 schrieb Jeremy Allison:
>> In practice this has never been an issue. It's only an issue
>> now due to the strange EA behavior. Once we have a vfs_lustre
>> module in place it will go back to not being an issue :-).
>
>The root of the problem seems to be an asymmetry in how Samba maps
>filesystem to Windows EAs and back. For SMB_INFO_SET_EA it's
>
>foo (Windows) ---> user.foo (filesystem)
>
>whereas SMB_INFO_QUERY_ALL_EAS map as
>
>user.foo  (filesystem) ---> foo (Windows)
>other.bar (filesystem) ---> other.bar (Windows)
>
>This means
>
>a) the Windows side cannot distinguish between other.bar and
>   user.other.bar, and
>b) a copy operation via Samba turns other.bar into user.other.bar
>   (leading to the issue at hand because the user.* EA namespace is off
>   by default in Lustre).
>
>So rather than adding a VFS module filtering some EAs, why not
>just make the mapping symmetric, ie.
>
>diff --git a/source3/smbd/smb2_trans2.c b/source3/smbd/smb2_trans2.c
>index 95cecce96e1..31a7a04a72c 100644
>--- a/source3/smbd/smb2_trans2.c
>+++ b/source3/smbd/smb2_trans2.c
>@@ -454,7 +454,7 @@ static NTSTATUS get_ea_list_from_fsp(TALLOC_CTX
>*mem_ctx,
>                struct ea_list *listp;
>                fstring dos_ea_name;
>
>-               if (strnequal(names[i], "system.", 7)
>+               if (!strnequal(names[i], "user.", 5)
>                    || samba_private_attr_name(names[i]))
>                        continue;
>
>
>What am I missing?
No, that's a decent patch I think. I would suggest submitting
it on Samba technical for consideration before creating a gitlab
MR, just in case there's something I've missed. But rejecting
everything except "user." would seem a good idea I think.

Hello Jeremy,
Hello Daniel,

I've now opened bug 15186 where I tried to summarize the analysis and
current state of discussion.
> >The root of the problem seems to be an asymmetry in how Samba maps
> >filesystem to Windows EAs and back. For SMB_INFO_SET_EA it's
> >
> >foo (Windows) ---> user.foo (filesystem)
> >
> >whereas SMB_INFO_QUERY_ALL_EAS map as
> >
> >user.foo  (filesystem) ---> foo (Windows)
> >other.bar (filesystem) ---> other.bar (Windows)
> >
> >This means
> >
> >a) the Windows side cannot distinguish between other.bar and
> >   user.other.bar, and
> >b) a copy operation via Samba turns other.bar into user.other.bar
> >   (leading to the issue at hand because the user.* EA namespace is off
> >   by default in Lustre).
> >
> >So rather than adding a VFS module filtering some EAs, why not
> >just make the mapping symmetric, ie.
> >
> >diff --git a/source3/smbd/smb2_trans2.c b/source3/smbd/smb2_trans2.c
> >index 95cecce96e1..31a7a04a72c 100644
> >--- a/source3/smbd/smb2_trans2.c
> >+++ b/source3/smbd/smb2_trans2.c
> >@@ -454,7 +454,7 @@ static NTSTATUS get_ea_list_from_fsp(TALLOC_CTX
> >*mem_ctx,
> >                struct ea_list *listp;
> >                fstring dos_ea_name;
> >
> >-               if (strnequal(names[i], "system.", 7)
> >+               if (!strnequal(names[i], "user.", 5)
> >                    || samba_private_attr_name(names[i]))
> >                        continue;
> >
> >
> >What am I missing?
> No, that's a decent patch I think. I would suggest submitting
> it on Samba technical for consideration before creating a gitlab
> MR, just in case there's something I've missed. But rejecting
> everything except "user." would seem a good idea I think.
+1 from me FWIW.
-- 
Thanks,
Michael