updated ksmbd (cifsd)
jra at samba.org
Tue Dec 15 04:13:38 UTC 2020
On Tue, Dec 15, 2020 at 11:29:01AM +0900, Namjae Jeon via samba-technical wrote:
>> 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-
>> >> 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:
>> > 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.
Yes, Samba could add an adaptor to read the ksmbd metadata format,
but then files written by Samba would have metadata unreadable
As the Samba metadata format is widely used then I don't see
the purpose of creating a new format for this. It's needless
incompatibility. Please fix this before submitting anywhere.
More information about the samba-technical