[Twg] Lustre Requirements and Roadmap

[Nathan Rutman]

Is it possible to get a list of all the Lustre-centric projects / enhancements that various groups are working on already?
Wide striping? Imperative recovery? Readdir+?  NRS?
Should these be removed, or at least noted as "in progress by _responsible party_" on the OpenSFS requirements list?


On Jan 27, 2011, at 12:44 PM, Atul Vidwansa wrote:

> 
> Summary of F2F Requirements Discussion (1/26/2011)
> --------------------------------------------------
> In the last few weeks, the TWG members gathered the following requirements from within their organizations and the Lustre community:
> 
>   - Improved error reporting
>   - Online filesystem integrity checks
>   - Integrated performance monitoring
>   - Completing OSD restructuring/kDMU work
>   - Size on MDS
>   - BTRFS investigation
>   - Imperative recovery
>   - Improved admin/mgmt tools
>   - Improved metadata performance
>   - LNET Channel Bonding
>   - end-to-end data integrity
>   - interface to HSM
> 
> Further discussion within the TWG organized these requirements into two high priority categories: 
> 
>   * improve metadata performance
>   * improve scalability and reliability of backend file system
> 
> At our 1/20 meeting, TWG members discussed several options to meet these
> goals:
> 
>   * metadata performance
>      - clustered metadata servers (CMD)
>      - network request scheduler (NRS)
>      - RPC aggregation
>      - SMP scaling
>      - subtree lockings
>      - size on MDS
> 
>   * backend storage
>      - OSD restructuring
>      - online fsck
>      - btrfs evaluation
> 
> Much of the design and implementation for these features was started by Sun/Oracle.  At the F2F meeting in Chicago, the OpenSFS board decided that there is an opportunity to acknowledge any technical debt in these initial designs and requested that, instead of an RFI for these features, the TWG specify our long-term requirements for Lustre and then engage the Lustre community to discuss architectures to meet these requirements.
> 
> Therefore, the TWG will spend the next two meetings refining the requirements for metadata and backend storage.  We will then spend the following two weeks leading discussions with the Lustre community to define the architecture and features that will meet the requirements.
> From these discussions, the TWG will create a roadmap that OpenSFS can use to direct feature development for Lustre 2.2 and beyond.
> 
> The following is an incomplete list of requirements to motivate further discussion : 
> 
>   * metadata performance
> 
>      GOAL: improve file system scalability and interactive
>            performance
> 
>      requirements:                    min            max
>      -  # files in file system    100 billion       1 trillion
>      -  # files in directory       50 million      10 billion
>      -  file creates / sec        100 thousand     30 thousand
>                                     (aggregate)      (single client)
>      -  directory lisings / sec
>      -  open files per process        -           100 thousand
>      -  file system capacity       30 PB          100 PB
>      -  # clients                  30 thousand    ?00 thousand
> 
> 
>   * backend storage
> 
>      GOAL: provide reliable, scalable backing store for 
>            Lustre servers
> 
>      requirements: 
>      -  large LUNs (min 32 TB)
>      -  end-to-end data integrity (T10 PI or equivalent)
>      -  no performance impact for file system repair
>      -  framework to enable alternatives to ldiskfs
>      -  direct I/O mode
>      -  ??
> 
> 
______________________________________________________________________
This email may contain privileged or confidential information, which should only be used for the purpose for which it was sent by Xyratex. No further rights or licenses are granted to use such information. If you are not the intended recipient of this message, please notify the sender by return and delete it. You may not use, copy, disclose or rely on the information contained in it.
 
Internet email is susceptible to data corruption, interception and unauthorised amendment for which Xyratex does not accept liability. While we have taken reasonable precautions to ensure that this email is free of viruses, Xyratex does not accept liability for the presence of any computer viruses in this email, nor for any losses caused as a result of viruses.
 
Xyratex Technology Limited (03134912), Registered in England & Wales, Registered Office, Langstone Road, Havant, Hampshire, PO9 1SA.
 
The Xyratex group of companies also includes, Xyratex Ltd, registered in Bermuda, Xyratex International Inc, registered in California, Xyratex (Malaysia) Sdn Bhd registered in Malaysia, Xyratex Technology (Wuxi) Co Ltd registered in The People's Republic of China and Xyratex Japan Limited registered in Japan.
______________________________________________________________________