[lustre-discuss] Call for Submission for the IO500 List

[John Bent]

*Call for SubmissionDeadline: 10 November 2019 AoEThe IO500
 is now accepting and encouraging submissions for the
upcoming 5th IO500 list revealed at SC19 in Denver, Colorado. Once again,
we are also accepting submissions to the 10 Node I/O Challenge to encourage
submission of small scale results. The new ranked lists will be announced
at our SC19 BoF [2]. We hope to see you, and your results, there. We have
updated our submission rules [3]. This year, we will have a new list for
the Student Cluster Competition as IO500 is used for extra points during
this competitionThe benchmark suite is designed to be easy to run and the
community has multiple active support channels to help with any questions.
Please submit and we look forward to seeing many of you at SC19! Please
note that submissions of all sizes are welcome; the site has customizable
sorting so it is possible to submit on a small system and still get a very
good per-client score for example. Additionally, the list is about much
more than just the raw rank; all submissions help the community by
collecting and publishing a wider corpus of data. More details
below.Following the success of the Top500 in collecting and analyzing
historical trends in supercomputer technology and evolution, the IO500
 was created in 2017, published its first list at SC17,
and has grown exponentially since then. The need for such an initiative has
long been known within High-Performance Computing; however, defining
appropriate benchmarks had long been challenging. Despite this challenge,
the community, after long and spirited discussion, finally reached
consensus on a suite of benchmarks and a metric for resolving the scores
into a single ranking.The multi-fold goals of the benchmark suite are as
follows: 1. Maximizing simplicity in running the benchmark suite2.
Encouraging complexity in tuning for performance3. Allowing submitters to
highlight their “hero run” performance numbers4. Forcing submitters to
simultaneously report performance for challenging IO patterns.Specifically,
the benchmark suite includes a hero-run of both IOR and mdtest configured
however possible to maximize performance and establish an upper-bound for
performance. It also includes an IOR and mdtest run with highly prescribed
parameters in an attempt to determine a lower-bound. Finally, it includes a
namespace search as this has been determined to be a highly sought-after
feature in HPC storage systems that have historically not been
well-measured. Submitters are encouraged to share their tuning insights for
publication.The goals of the community are also multi-fold: 1. Gather
historical data for the sake of analysis and to aid predictions of storage
futures2. Collect tuning information to share valuable performance
optimizations across the community3. Encourage vendors and designers to
optimize for workloads beyond “hero runs”4. Establish bounded expectations
for users, procurers, and administrators10 Node I/O ChallengeAt SC, we will
continue the 10 Node Challenge. This challenge is conducted using the
regular IO500 benchmark, however, with the rule that exactly 10 computes
nodes must be used to run the benchmark (one exception is the find, which
may use 1 node). You may use any shared storage with, e.g., any number of
servers. We will announce the result in a separate derived list and in the
full list but not on the ranked IO500 list at io500.org
.Birds-of-a-featherOnce again, we encourage you to submit
[1], to join our community, and to attend our BoF “The IO500 and the
Virtual Institute of I/O” at SC19, November 19th, 12:15-1:15pm, room
205-207, where we will announce the new IO500 list, the 10 node challenge
list, and the Student Cluster Competition list. We look forward to
answering any questions or concerns you might have. - [1]
http://io500.org/submission - [2]
https://www.vi4io.org/io500/bofs/sc19/start
- [3]
https://www.vi4io.org/io500/rules/submission
 The IO500 committee*
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] CPU soft lockup on mkfs.lustre

[Peter Jones]

I’ve created one for you. Check your spam folder if you have not already 
received an automated email with your login credentials.

From: lustre-discuss  on behalf of 
Tamas Kazinczy 
Organization: Governmental Agency for IT Development
Date: Thursday, September 12, 2019 at 12:14 AM
To: Patrick Farrell , "Degremont, Aurelien" 
, "lustre-discuss@lists.lustre.org" 

Subject: Re: [lustre-discuss] CPU soft lockup on mkfs.lustre



On 2019. 09. 11. 15:53, Patrick Farrell wrote:
Tamas, Aurélien,

Would one of you mind opening an LU on this?

I would do that though I don't have an account yet.



Cheers,

--

Tamás Kazinczy
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] Do not recreate OST objects on OST replacement

[Andreas Dilger]

On Sep 10, 2019, at 10:23, Degremont, Aurelien 
mailto:degre...@amazon.com>> wrote:

Hello

When an OST dies and you have no choice but replacing it with a newly freshly 
formatted one (using mkfs --replace), Lustre runs a resynchronization 
mechanisms between the MDT and the OST.
The MDT will sent the last object ID it knows for this OST and the OST will 
compare this value with its own counter (0 for a freshly formatted OST).
If the difference is greater than 100,000 objects, it will recreate only the 
last 10,000, if not, it will recreate all the missing objects.

I would like it to avoid recreating any objects. The missing ones are lost and 
just start recreating new ones. Is there a way to achieve that?

It isn't currently possible to completely avoid recreating these objects.  
Normally it isn't a huge problem, given the size of normal OSTs.  This is done 
to ensure that if the MDS has previously allocated those objects there will be 
objects available for the clients to write to them. LFSCK can be used to clean 
up these orphan objects if they are not in use.


Cheers, Andreas
--
Andreas Dilger
Principal Lustre Architect
Whamcloud






___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org

Re: [lustre-discuss] CPU soft lockup on mkfs.lustre

[Tamas Kazinczy]

On 2019. 09. 11. 15:53, Patrick Farrell wrote:

Tamas, Aurélien,

Would one of you mind opening an LU on this?


I would do that though I don't have an account yet.


Cheers,

--
Tamás Kazinczy

___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org