<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
Ah, thanks Andreas. Perhaps not coincidentally, Lustre 2.4 is the first release I worked on.<br>
<br>
Neil, I am really unenamored of the idea of the shared ptlrpc ldlm module being named ptlrpc...<br>
<br>
Also, Lustre currently has a bunch of module parameters which are used for configuration. Thoughts on that?<br>
<br>
<br>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Andreas Dilger <adilger@dilger.ca><br>
<b>Sent:</b> Thursday, June 21, 2018 2:22:45 AM<br>
<b>To:</b> James Simmons<br>
<b>Cc:</b> Patrick Farrell; Lustre Development List<br>
<b>Subject:</b> Re: [lustre-devel] [PATCH 00/24] lustre - more cleanups including module reduction.</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Jun 20, 2018, at 8:57 PM, James Simmons <jsimmons@infradead.org> wrote:<br>
> <br>
>> <br>
>> Huh? Very little of the client is used on the server. The vast majority of the client is llite, vvp, then lov, osc, and mdc. These are<br>
>> not used on the servers at all, the modules won't even be loaded.<br>
>> <br>
>> <br>
>> Servers are definitely *not* clients of one another in the sense of "Lustre clients". They interact with each other, but in a manner very<br>
>> different from client to server.<br>
>> <br>
>> The ldlm and ptlrpc layers are *partly* shared, and of course, the networking from lnet down is. But that's not "the client".<br>
>> <br>
>> The statement that the server layer is a middle layer on top of the client code doesn't make any sense to me. It's like this:<br>
>> <br>
>> <br>
>> vfs<br>
>> client code<br>
>> ptlrpc<br>
>> networking<br>
>> ------ PHYSICAL BOUNDARY --------<br>
>> networking<br>
>> ptlrpc<br>
>> server code<br>
>> ldiskfs<br>
>> <br>
>> <br>
>> <br>
>> with LDLM also being explicitly shared, though client & server code is not all shared. Very little to nothing outside of the networking &<br>
>> ldlm layers is shared.<br>
> <br>
> When I first started this (pre 2.3 days) that is how it was explained to<br>
> me. I just took it at face value but when it comes to the separation as I<br>
> don't have a clue. Patrick since you have a better grasp of the<br>
> architecture can you provide details to Neil. Perhaps to documentation on<br>
> this separation if it exist.<br>
<br>
James,<br>
you are (or were) correct, but the code has evolved over the years. The lov/osc and<br>
modules were formerly used on the MDS in order to connect to the OSS, and lmv/mdc were<br>
used with the old CMD code to connect to other MDS nodes. However, that ended up with<br>
a lot of code that was in those modules that was only used on the client or server. In<br>
the CMD code it also meant that a lot of complexity existed with making "fake" RPCs to<br>
other MDS nodes that tried to keep the same RPC opcode but were interpreted differently<br>
at the MDS when they were being sent from another MDS.<br>
<br>
In the 2.4 release (which included both DNE and the OSD rewrite for ZFS) the lov/osc<br>
server code was copied/split into lod/osp, and this is used for remote connections to<br>
both the OSSs and other MDS nodes. The MDS is still a client of the OSS for precreate<br>
and recovery operations (and soon also statfs), but the code is no longer shared with<br>
the regular clients.<br>
<br>
Cheers, Andreas<br>
<br>
<br>
<br>
<br>
<br>
</div>
</span></font></div>
</body>
</html>