Re: [RFC PATCH 0/9] sunrpc: teach the SUNRPC layer how to speak SMB

On Sun, Sep 27, 2009 at 11:50 AM, Jeff Layton <[email protected]> wrote:

> This patchset is still preliminary and is just an RFC...
>
> First, some background. When I was at Connectathon this year, Trond
> mentioned an interesting idea to me. He said (paraphrasing):
>
> "Why doesn't CIFS just use the RPC layer for transport? It's very
> efficient at shoveling bits out onto the wire. You'd just need to
> abstract out the XDR/RPC specific bits."
>
> The idea has been floating around in the back of my head until recently,
> when I decided to give it a go. This patchset represents a first, rough
> draft at a patchset to do this. There's also a proof of concept module
> that demonstrates that it works as expected.
>
> The patchset is still very rough. Reconnect behavior is still very
> "RPC-ish", for instance. There are doubtless other changes that will
> need to be made before I had anything merge-worthy.
>
> At this point, I'm just interested in feedback on the general approach.
> Should I continue to pursue this or is it a non-starter for some
> reason?
>
> The next step here, obviously is to start building a fs on top of it.
> I'd particularly be interested in using this as a foundation of a
> new smb2fs.
>
> I've also got this patchset up on my public git tree:
>
>    http://git.samba.org/?p=jlayton/cifs.git;a=summary
>
> Here are some questions I anticipate on this, and their answers:
>
> ------------------------------------------------------------------------
> Q: Are you insane? Why would you attempt to do this?
>
> A: Maybe...but in the last couple of years, I've spent a substantial
> amount of time working on the CIFS code. Much of that time has been
> spent fixing bugs. Many of those bugs exist in the low-level transport
> code which has been hacked on, kludged around and hand tweaked to
> where it is today. Unfortunately that's made it a very hard to work
> on mess. This drives away potential developers.
>
> CIFS in particular is also designed around synchronous ops, which
> seriously limits throughput. Retrofitting it for asynchronous operation
> will be adding even more kludges. The sunrpc code is already
> fundamentally asynchronous.
> ------------------------------------------------------------------------
> Q: Okay, what's the benefit of hooking it up to sunrpc rather than
> building a new transport layer (or fixing the transport in the other two
> filesystems)?
>
> A: Using sunrpc allows us to share a lot of the rpc scheduler code with
> sunrpc. At a high level, NFS/RPC and SMB aren't really very different.
> Sure, they have different formats, and one is big endian on the wire and
> the other isn't...still there are significant similarities.
>
> We also get access to the great upcall mechanisms that sunrpc has, and
> the possibility to share code like the gssapi upcalls. The sunrpc layer
> has a credential and authentication management framework that we can
> build on to make a truly multiuser CIFS/SMB filesystem.
>
> I've heard it claimed before that Linux's sunrpc layer is
> over-engineered, but in this case that works in our favor...
> ------------------------------------------------------------------------
> Q: can we hook up cifs or smbfs to use this as a transport?
>
> A: Not trivially. CIFS in particular is not designed with each call
> having discrete encode and decode functions. They're sort of mashed
> together. smbfs might be possible...I'm a little less familiar with it,
> but it does have a transport layer that more closely resembles the
> sunrpc one. Still though, it'd take significant work to make that
> happen. I'm not opposed to the idea however.
>
> In the end though, I think we'll probably need to design something new
> to sit on top of this. We will probably be able to borrow code and
> concepts from the other filesystems however.
> ------------------------------------------------------------------------
> Q: could we use this as a transport layer for a smb2fs ?
>
> A: Yes, I think so. This particular prototype is build around SMB1, but
> SMB2 could be supported with only minor modifications. One of the
> reasons for sending this patchset now before I've built a filesystem on
> top of it is because I know that SMB2 work is in progress. I'd like to
> see it based around a more asynchronous transport model, or at least
> built with cleaner layering so that we can eventually bolt on a different
> transport layer if we so choose.
>
> Jeff Layton (9):
>  sunrpc: abstract out encoding function at rpc_clnt level
>  sunrpc: move check for too small reply size into rpc_verify_header
>  sunrpc: abstract our call decoding routine
>  sunrpc: move rpc_xdr_buf_init to clnt.h
>  sunrpc: make call_bind non-static
>  sunrpc: add new SMB transport class for sunrpc
>  sunrpc: add encoding and decoding routines for SMB
>  sunrpc: add Kconfig option for CONFIG_SUNRPC_SMB
>  smbtest: simple module for testing SMB/RPC code
>
>  fs/Makefile                    |    2 +
>  fs/lockd/host.c                |    4 +
>  fs/lockd/mon.c                 |    4 +
>  fs/nfs/client.c                |    4 +
>  fs/nfs/mount_clnt.c            |    4 +
>  fs/nfsd/nfs4callback.c         |    4 +
>  fs/smbtest/Makefile            |    1 +
>  fs/smbtest/smbtest.c           |  204 +++++
>  include/linux/sunrpc/clnt.h    |   24 +-
>  include/linux/sunrpc/smb.h     |   42 +
>  include/linux/sunrpc/xprtsmb.h |   59 ++
>  net/sunrpc/Kconfig             |   11 +
>  net/sunrpc/Makefile            |    1 +
>  net/sunrpc/clnt.c              |   98 ++-
>  net/sunrpc/rpcb_clnt.c         |    8 +
>  net/sunrpc/smb.c               |  120 +++
>  net/sunrpc/sunrpc_syms.c       |    3 +
>  net/sunrpc/xprtsmb.c           | 1723
> ++++++++++++++++++++++++++++++++++++++++
>  18 files changed, 2272 insertions(+), 44 deletions(-)
>  create mode 100644 fs/smbtest/Makefile
>  create mode 100644 fs/smbtest/smbtest.c
>  create mode 100644 include/linux/sunrpc/smb.h
>  create mode 100644 include/linux/sunrpc/xprtsmb.h
>  create mode 100644 net/sunrpc/smb.c
>  create mode 100644 net/sunrpc/xprtsmb.c
>
> _______________________________________________
> linux-cifs-client mailing list
> [email protected]
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>


Jeff,

So servers need to speak SUNRPC as well right?
Are_threre/how_many servers are out there that speak CIFS/SMB over SUNRPC or
SMB2 over SUNRPC?

_______________________________________________
linux-cifs-client mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/linux-cifs-client