> On Mon, Dec 14, 2020 at 06:45:51PM +0100, Stefan Metzmacher via samba-technical wrote: > >Am 14.12.20 um 02:20 schrieb Steve French via samba-technical: > >> I just rebased https://protect2.fireeye.com/v1/url?k=e100f21c-be9bcb17-e1017953-002590f5b904- > f00629b46b3afee4&q=1&e=6fc8b980-0fd2-4e4d-a9dc- > 9ea15e482833&u=https%3A%2F%2Fgithub.com%2Fsmfrench%2Fsmb3-kernel%2Ftree%2Fcifsd-for-next > >> ontop of 5.10 kernel. Let me know if you see any problems. xfstest > >> results (and recent improvements) running Linux cifs.ko->ksmbd look > >> very promising. > > > >I just looked briefly, but I'm wondering about a few things: > > > >1. The xattr's to store additional meta data are not compatible with > > Samba's way of storing things: > > > >https://protect2.fireeye.com/v1/url?k=fbb13e03-a42a0708-fbb0b54c-002590 > >f5b904-f4288e37b0eb9ae8&q=1&e=6fc8b980-0fd2-4e4d-a9dc-9ea15e482833&u=ht > >tps%3A%2F%2Fgit.samba.org%2F%3Fp%3Dsamba.git%3Ba%3Dblob%3Bf%3Dlibrpc%2F > >idl%2Fxattr.idl > > > > In order to make it possible to use the same filesystem with both servers > > it would be great if the well established way used in Samba would be used > > as well. > > A thousand times this ! If cifs.ko->ksmbd adds a differnt way of storing the extra meta-data that is > incompatible with Samba this would be a disaster for users. > > Please fix this before proposing any merge. You said that samba can handle it even if ksmbd has own extra metadata format. I didn't think it was necessary to what you said. If we have to do this, I think it is not too late to work after sending ksmbd to linux-next first.
