5 ms·
My main reason for wanting ksmbd is that it's tiny (a few hundred k I believe). The smallest Samba build I've seen is ~40MB, and not very portable at all. I pre
by anderspitman 4y ago
My main reason for wanting ksmbd is that it's tiny (a few hundred k I believe). The smallest Samba build I've seen is ~40MB, and not very portable at all. I pretty much had to use buildroot to make it work.
My use case is shipping minimal Linux kernels + initramfs that can be run with QEMU. I need file sharing and SMB is the most universal protocol. I can ship the entire kernel (~5MB) and QEMU (~15MB) in less space than Samba. I would love a minimal build.
- jart 4y agoWhere can I get copies of your kernel builds and how can I run them? What's the tiniest possible one you've made?
- anderspitman 4y agoI don't have them hosted anywhere. I'd recommend playing with buildroot. It's very simple and mostly just works. Using the provided QEMU config yields a kernel that's about 5MB. I believe user space (a la BusyBox) was about another 5MB. Haven't done much tuning beyond that. Feel free to email me if you have questions.
- topspin 4y ago> My main reason for wanting ksmbd is that it's tiny That's a fine reason. Does it have to be in the kernel to be small though? From what I can see ksmpd is small because it delivers only a minimal SMB3, not because it's in-kernel. Why would a user space SMB3 be appreciably larger? Also, the performance hopes for ksmbd don't appear valid either. By adopting io_uring and splice(2) Samba now outperforms[1] ksmbd by a wide margin. Those results are a year old and may be out of date, but still, I suspect we're getting so close to the limits of hardware that it doesn't matter. Another argument for in-kernel is SMB Direct: SMB over RDMA. Yet here[2] we see io_uring is receiving the bits needed for that as well. Finally, the license issue: I can't think of a reason a GPL2/Berkeley licensed SMB3 couldn't be in user space. Where am I wrong? Is there a valid reason for this to be in kernel? I don't see one. [1] https://samba.plus/blog/detail/ksmbd-a-new-in-kernel-smb-server https://samba.plus/blog/detail/ksmbd-a-new-in-kernel-smb-ser... [2] https://lwn.net/Articles/879724/ https://lwn.net/Articles/879724/ Edit: looks like the ksmbd SMB Direct work predates the io_uring RDMA capability by a few years, so at that time SMB Direct was a legitimate reason. On the other hand send(..., MSG_ZEROCOPY) predates ksmbd...
- darkwater 4y agoI think the biggest reason here, especially for GP, is that ksmb3 already exists now (and it existed for a few years), while your tiny smb3 does not exist yet.
- anderspitman 4y agoBasically this. I would love a small uaerspace implementation. Even if it had worse performance that's not the most important thing for me.
- topspin 4y agoOk, so now that we've exhausted the regression of invalid reasons we're left with what? Someone made it so in it goes? Enjoy the CVEs I guess.
- darkwater 4y agoIt just means that a better solution that fulfill all their needs doesn't exist yet, and they decided to take one trade-off rather than another one. Maybe in that setup a possible RCE is not that dangerous.
- ilyt 4y ago"I need to share files but can't spare 40MB of space for OS" is quite rare case tho
- anderspitman 4y agoMy application is rather unique. It involves shipping VM images to end users. Which means the images can be downloaded many times. But the files shared over SMB would be the user's own files.