[lustre-discuss] lustre vs. lustre-client

[Andreas Dilger]

On Aug 9, 2018, at 18:51, Faaland, Olaf P. <faaland1 at llnl.gov> wrote:
> 
> Hi,
> 
> What is the reason for naming the package "lustre" if it includes both client and server binaries, but "lustre-client" if it includes only the client?
> 
> ===== (from
> # Set the package name prefix
> %if %{undefined lustre_name}
>    %if %{with servers}
>        %global lustre_name lustre
>    %else
>        %global lustre_name lustre-client
>    %endif
> %endif
> =====
> 
> Are there sites that build both with and without servers, and need to keep track which is installed on a given machine?  The size of the RPMs isn't that different, so it's not obvious to me why one would do that.

The original reason for separate "lustre" and "lustre-client" packages was
that the "lustre-client" package was built against a patchless kernel, so
that it could be installed on unmodified client systems.  At the time, this
was a departure from the all-inclusive "lustre" package that was always
built against a patched kernel.

Until not so long ago, it wasn't possible to build a server against an
upatched kernel, but that has been working for a while now.  We do build
"patched" and "unpatched" server RPMs today, but haven't gotten around to
changing the packaging to match.

At this point, I think it makes sense to just move over to RPMs for patched
and unpatched kernels, and get rid of the "-client" package.  Alternately,
we could have "lustre-client", "lustre-server", and "lustre-common" RPMs,
but (IMHO) that just adds more confusion for the users, and doesn't really
reduce the package size significantly (only a handful of modules would be
different between the client and server).

Having a patched server kernel isn't needed for ZFS, and while it works for
ldiskfs as well, there are still a few kernel patches that improve ldiskfs
server performance/functionality that are not in RHEL7 (e.g. project quota,
the upcoming T10-PI interface changes) that make it desirable to keep both
options until those changes are in vendor kernels.

Cheers, Andreas
---
Andreas Dilger
Principal Lustre Architect
Whamcloud







-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20180810/b99f5a9a/attachment.sig>