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