[cdwg] Lustre 2.5 Development Planning

[Dilger, Andreas]

On 2013/03/06 11:41 AM, "James A Simmons" <uja at ornl.gov> wrote:

>On Wed, 2013-05-22 at 13:41 -0400, Christopher J. Morrone wrote:
>> Hi folks,
>> 
>> Please send us your list of planned development items for Lustre 2.5!
>> In two weeks at the next CDWG meeting we will be looking at the list of
>> proposed work and making our first, best attempt at pare it down to a
>> reasonable set of work for Lustre 2.5.
>> 
>> If you have a new feature that you believe will be ready to land with
>>in 
>> the three month feature-landing window of Lustre 2.5, NOW is the time
>>to 
>> tell us!
>
>One I have act as the SuSE police to make sure ldiskfs is kept in sync.
>This covers all the ldiskfs work that will happen in 2.5. That will be
>done mostly by me.
>
>besides SLES11 other ldiskfs work
>--------------------------------------------------
>LU-2479 - fix max_dir_size checking
>LU-2761 - sync ext4-kvalloc and journal callback
>LU-2762   to what is used mainline
>
>Lustre support against tip of Linus tree
>--------------------------------------------------
>LU-1812 - 3.6/FC18 server patches
>LU-2686 - 3.7.2-201.fc18 client support
>LU-2800 - autoconf cleanup and code update for newer kernels.
>LU-2850 - 3.8 kernel support
>LU-2987 - llite destroy_inode should call rcu free
>LU-3097 - 3.9 kernel support
>
>Patchless Lustre
>--------------------------------------------------------------
>LU-20   - Remove server side patches. Send block tunable
>	  patches upstream. Sub task below:
>
>LU-2498 - set IO scheduler to "deadline"
>LU-2757 - move dynlocks to osd-ldiskfs

Most of these are fine, since they involve porting patches that already
exist.


>LU-3406 - merge raid5-mmp-unplug patch upstream
>LU-2442 - quota scaling improvements. Need to be pushed
>LU-3305   upstream

These depend on the willingness of the upstream patch maintainers to
accept.
Definitely something to track, but no guarantee of completion in 2.5.

> LU-684 - dev_rdonly patch is replaced by linux fail frame work.

This one doesn't have any existing patches, so needs new development work.


>and for the project I like to work on related to ldiskfs is to make
>ldiskfs patchless against the tip of Linus tree. Anything that will
>not be pushed upstream will be moved into osd-ldiskfs. No JIRA ticket
>for this work yet.

I'm definitely in support of this.  One of the main patches that needs work
to be accepted upstream is the large_xattr patch.  Please see LU-908 for
what needs to be done before this patch can land upstream.

The other major filesystem feature that is not yet landed upstream is the
dirdata feature, used for FID-in-dirent.  This doesn't have a lot of appeal
to non-Lustre users today, but there may be a way to get this included
upstream as part of an "attributes in dirent" feature that Ted discussed at
one time.  I'm not sure if he is working on that, but I can ask him.

>Misc Lustre improvements
>------------------------------------------------------------
>LU-549  - packaged xattr in single RPC reply

Xyratex is working on this feature, so Fan Yong's patches under LU-549 are
not planning on landing for 2.5.  Not sure if they have a separate tracker
for their work, or if they will reuse L-549.

>LU-2924 - shrink ldlm_poold workload
>LU-2145 - unified request handler for MGS
>LU-2059 - MGC to use OSD API
>LU-2158 - lvfs and fsfilt removal
>
>LNET work
>---------------------------------------------------------------
>LU-2456 - Dynamic LNET config support
>LU-2950 - LNET route config
>LU-2466 - LNET hash tables
>LU-2934 - Router Priority
>
>Enable LNET to process its own checksums and do hand shaking with
>the ptlrpc layer. No JIRA ticket for this yet.

Could you please explain this more?  What is the benefit of adding another
layer of checksumming at the LNEt level vs. the existing Lustre-level
checksums, except overhead?

>**********************************************************
>LNET change I would like so see these in 2.4.1 if possible as well :-)
>**********************************************************
>LU-2212 - add crc32c module loading to libcfs

There is no objection to this patch landing, except that nobody reported
that the patch for that bug actually said that the patch actually fixed
the problem for them.

>LU-2544 - SMP scaling to Gemini driver
>----------------------------------------------
>
>Wish list work for myself that I most likely will not have ready for
>2.5.X
>
>Enable compression of LNET traffic.

Is there an expectation that this will improve throughput under normal
usage, or would this only be good for WAN data transfers?  As it is, the
clients are already using considerable CPU for data handling, so I could
only see this helping if the client data compression went all the way to
the disk (i.e. it is compressed at the Lustre client, saved to disk in
compressed form, and then decompressed again at the Lustre client), not
at the LNET level.

>Fix up Lustre so it can be built with llvm. First step to compile some
>of the more cpu intensive code in lustre as TSGI code to be executed by
>the GPU.

This is theoretically interesting, but I'm not sure if there is any piece
of Lustre code which would actually benefit from GPU offloading.  I think
that is only useful for CPU-intensive code that is run in a tight loop.
It would also suffer if the code is doing data access, since it would need
to do all the data access over the PCI bus in addition to the existing two
network<->CPU<->storage transfers.

Given that Lustre does auto-negotiation of the best checksum algorithms
between the client and OST to use the hardware CRC support of the CPU, do
you have any candidates that might benefit from this?

Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division