在王堅博士的《線上》一書中提到，單純談資料的“大”，意義是不大的。歐洲核子研究中心（CERN）進行一次原子對撞産生的資料大到驚人，而如何通過計算的方式去挖掘出這些資料背後的價值，才是資料意義的本身。HPC高性能計算，就是完成這種價值轉換的重要手段。近年來，HPC的應用範圍已經從純學術擴充到資源勘探、氣象預測、流體力學分析、計算機輔助設計等更多場景。這些HPC應用程式會産生或依賴大量資料，并将其存儲在PB級别的共享的高性能檔案系統中。然而，無論是HPC應用的使用者，還是高性能檔案系統的開發人員，對這些檔案的通路模式了解都非常有限。
我們在Fast20中發現了一篇很有趣的論文《Uncovering Access, Reuse, and Sharing Characteristics of I/O-Intensive Files on Large-Scale Production HPC Systems》，這篇論文研究了超級計算機的生産環境上I/O密集型HPC應用對檔案通路模式。
據論文作者所知，這是第一篇對HPC系統中IO密集型檔案的通路、重複使用以及共享特性進行深入研究的論文。這篇論文第一次揭示了（1）HPC中的各個檔案是讀密集型，還是寫密集型，或是讀寫密集型；（2）在多個任務中，反複通路同一個檔案的時間間隔；（3）多個應用程式對同一個檔案的共享行為。更進一步地，這篇論文還基于檔案的IO時序，分析了導緻檔案系統性能低下的主要原因，這些原因導緻了在單次任務和多次任務間的IO的性能波動。
論文總結了十個發現，我們結合自己的了解，補充了很多背景知識，摘要了其中的要點，和大家做個分享（前方及其高能），大家可以細細品讀論文作者的研究思路和手段，也可以直接浏覽論文歸納的十大發現。以下文章中未注明的圖表，均來自論文原文（圖表标号使用原文中的标号）。感興趣的同學可以閱讀論文原文，也歡迎大家和我們一起讨論。
在大規模高性能計算HPC叢集上，各個應用的資料讀寫通常都在幾十上百TB。過往對于IO特征上的研究大多基于單個應用程式級别，針對特定應用提供底層存儲的優化建議。而大家對于HPC系統中不同應用程式對各種檔案的IO特點，了解非常有限。因為這需要在HPC生産環境中，跟蹤應用在大量任務執行過程中産生的IO資訊，衆所周知，這種細粒度的跟蹤和分析，對系統的性能是會造成很大影響的，這也正是很難在HPC的生産環境中進行類似研究的原因。然而，這種研究還是極具價值的，它對于我們存儲研發人員更深入了解針對檔案的IO、檔案反複讀寫的模式、IO性能上的波動、優化檔案放置政策，都非常有意義。
論文的研究使用的是輕量級的IO監控工具Darshan（Darshan旨在以最小的開銷捕獲應用程式IO行為的準确情況，包括檔案的通路模式等特征。Darshan名稱取自梵語單詞“ sight”或“ vision”， https://www.mcs.anl.gov/research/projects/darshan/），論文作者團隊在Top500超級計算機叢集Cori的生産環境上，進行了長達四個月（累計近3600萬個節點小時）的跟蹤和分析。
首先介紹一下Cori，超級計算機叢集Cori在最新的世界HPC Top500中排名第十三位（https://www.top500.org/list/2019/11/），Cori具備約27 Pflop / s的峰值計算性能，包含9,688個Intel Xeon Phi和2388個Intel Haswell處理器。Cori使用的是基于磁盤的Lustre檔案系統，該檔案系統由約10,000塊磁盤組成，這些磁盤被組織為248個Lustre OST。每個OST都配置有GridRAID，并具有用于處理IO請求的相應的OSS。檔案系統的總大小約為30 PB，IO峰值帶寬為744 GB / s。Cori是長這樣的：
圖檔來自網際網路
IO資料監控和采集。論文作者使用Darshan這個監控工具對應用程式進行檔案IO通路模式等特征的收集。在研究期間，Cori上所有使用者都預設啟用了Darshan V3.10。Darshan收集了包括使用者ID、作業ID、應用程式ID、開始時間戳、結束時間戳和程序數等關鍵資訊。Darshan還針對代表性的IO接口類型 POSIX IO、MPI IO（Message Passing Interface，MPI是一種用于對并行計算機進行程式設計的通信協定，是一個用于進行消息傳遞的應用程式程式接口、協定和語義規範，MPI是當今高性能計算中被廣泛使用的IO程式設計模型，這種程式設計模型需要底層存儲的支援）、STD（Standard）IO的IO調用接口進行了監控和統計。統計的名額包括讀/寫資料量、讀/寫/元操作的總時間、執行IO的程序ID，以及不同應用程式程序中IO大小和IO時間的波動。最後，Darshan還收集了Lustre檔案系統級别的一些名額，例如條帶寬度和對檔案條帶化所涉及的OST ID。但是，Darshan沒有記錄各個檔案的實際大小，而隻記錄了檔案被傳輸的資料的大小。在論文研究期間，作者團隊供收集了大約8400萬條日志（每次任務執行對應一條日志），這些日志涵蓋在8489個應用程式的5200萬個日志檔案中，涉及651個使用者和12.8 PB的資料傳輸（其中6.9 PB讀取資料，5.9 PB寫入資料）。
在以下篇幅中，會使用到幾種圖表，包括：
熱度分布圖，用于顯示兩個名額之間特定關系的關聯程度。熱度分布圖顔色的強度表示顯示兩個坐标名額上對應的檔案數。
CMF圖。CMF圖用于顯示橫軸名額的累積分布。垂直的藍色虛線用于訓示橫軸名額的平均值。
一些CMF圖顯示的是一個名額的CoV（變異波動系數（％），https://en.wikipedia.org/wiki/Coefficient_of_variation）的累計分布（簡單來說，就是這個名額在多大範圍内波動的累計機率情況），以突出顯示這個名額的歸一化波動特性。
Violin Plot，這些圖用于以垂直格式顯示名額不同值的密度（以檔案數表示），水準的藍色實線用于訓示密度分布的平均值。
如何選擇IO密集型檔案
前面提到過，Cori的Darshan日志包含了約5200萬個檔案。但是，分析表明，在研究期間，大多數日志檔案中執行的IO操作很少。圖2橫坐标表示計算任務中一個檔案的傳輸資料量（讀或寫），縱坐标表示一個檔案在多少個任務中被讀寫，不同色塊代表涉及的檔案數量。從圖中可以看出，大多數檔案的IO小于100 GB，并且整個計算過程中隻被通路一次。實際上，超過99％的檔案傳輸資料少于1 GB。這并不意味着實際檔案大小小于1 GB，隻是檔案的資料傳輸量小于1 GB。
Figure 2: 超過99%（約等于5200萬個）的檔案傳輸數量<1GB，且研究期間隻被通路一次
是以，大多數的檔案對建立與HPC應用程式的主要IO模型有關的特征沒有幫助。這些檔案包括使用者注釋、腳本、可執行檔案、非IO密集型應用程式輸出以及錯誤日志等。而論文的研究重點是 “IO密集型”檔案，這些檔案在研究期間至少完成了100 GB的資料傳輸，并且至少被2次任務通路，作者通過研究這些IO密集型檔案以捕獲最主要和最具代表性的IO模式。從這裡開始，将這些IO密集型檔案簡稱為“檔案”。這些IO密集型檔案的日志跨越了約40萬次任務、791個應用程式、149個使用者、8500個檔案和7.8 PB的資料傳輸（4.7 PB的讀取資料和3.1 PB的寫入資料），超過70％的使用者對2個以上的檔案執行IO操作，每個使用者平均對57個檔案執行IO。
檔案分類
接下來，作者根據IO密集型檔案執行的IO操作類型對這些檔案進行分類，這有助于了解後續章節中針對不同類型檔案通路特點所得到的發現。圖3（a）顯示了每個檔案讀取資料傳輸量與寫入資料傳輸量的熱力圖。檔案可以分為三個不同的種類，右下方的一組由22％的檔案組成，這些檔案在四個月内傳輸的大部分為讀取資料，論文将這些檔案稱為讀密集型檔案或RH（Read-Heavy）檔案。左上方的一組由僅傳輸寫資料的檔案（寫密集型檔案或WH（Write-Heavy）檔案）組成，占IO密集型檔案的7％。位于檔案右上角的一組具有最大的占比（占71％），由讀寫密集型檔案組成（稱為RW（Read-Write）檔案）。
Figure 3: (a) IO密集型檔案分為三組-讀密集型/寫密集型/讀寫密集型
發現1. HPC檔案可分為讀密集型（RH）、寫密集型（WH）或讀寫密集型（RW）。論文首次量化了檔案中有很大一部分是讀密集型的檔案（占22％），小部分是寫密集型檔案（占7％），這7％的檔案被不斷寫入，但未被讀取。有71％的HPC檔案是RW檔案（即讀寫密集型檔案）。這種的檔案分類可用于設定檔案放置決策，包括Burst Buffer區在内的分層存儲放置政策，其中每個層分别适用于不同類型的IO操作。
讀寫任務分類
盡管可以将檔案根據IO類型分為三種，但它們可以被多個“應用程式的任務”通路，各任務都可以執行讀取和寫入操作。任務是指在計算節點上運作的各種作業，由一個節點内的多個MPI程序以及可能的共享記憶體的線程組成。作者發現，絕大多數任務要麼執行讀密集型操作，要麼執行寫密集型。為了證明這一點，作者使用以下公式計算每次任務的讀寫資料量之差：|資料讀取-寫入資料| /（資料讀取+寫入資料）。該公式的值範圍是0到1，1表示任務所處理的所有資料都是隻讀或隻寫，0表示讀取和寫入資料傳輸量相等。圖3（b）顯示所有任務中，超過82％的值非常接近1，即它們是讀密集型或寫密集型的。在IO上下文中，作者将讀密集型任務簡稱為“讀任務”，将寫密集型任務稱為“寫任務”。作者發現其中69％是讀密集型任務，而31％是寫密集型任務。RH檔案主要由讀密集型任務讀取，WH檔案主要由寫密集型任務寫入，這兩類任務都會對RW檔案進行操作。對任務的分類有助于在後續章節中建立任務之間的生産者-消費者關系模型。
Figure 3: (b) >82% 的任務隻執行讀或寫操作
發現2.令人驚訝的是，現代HPC應用程式在單次任務中主要傾向于僅執行一種類型的IO：要麼讀，要麼寫。這與普遍認為HPC應用程式在一個任務期間，同時具有讀取和寫入IO階段的假設相反。這一發現表明，更科學的工作流逐漸取代了傳統的單體化應用程式（将不同工作彙集到一個任務中）的設計。非單體化應用程式的存在，為更好地排程大型工作流的不同元件提供了機會，進而避免了不同工作流之間的IO争用。
接下來，論文分析了多任務重複通路資料及多應用共享資料的特點，并研究了負載是否均衡，以及任務内和不同任務間IO波動的特征。
檔案複用的特點
在之前，作者将任務分為了讀任務或寫任務，并且發現讀任務的總數約為寫任務數量的2倍。接下來，為了了解複用同一檔案所花費的平均時間（任務到達時間定義如圖4所示），作者定義了不同任務的到達時間的概念。
Figure 4: 同一個檔案讀任務或寫任務間隔的定義
圖5（a）顯示，同一個檔案經曆的不同讀任務的平均到達時間間隔為47小時，而寫任務的平均到達時間間隔為55小時。但是，平均而言，80％的檔案隻有在50-55小時後才會再次被讀取和寫入。作者注意到，平均到達間隔時間比Cori上作業的平均運作時間長得多（這些系統上> 80％的HPC作業在不到2小時内完成）。
Figure 5(a): 大多數情況下對同一個檔案的再次通路間隔時間在50-55小時
發現3.對于80％的檔案，讀寫任務具有相似的到達時間間隔，都超過2天。論文首次發現，大多數檔案重新通路時間間隔（>50小時）比作業的運作時間更長。這意味着HPC系統有時間對一些希望在一段時間内不活躍的資料進行壓縮，或者将一些接下來即将通路到的資料通過預讀和緩存的方式加載到Burst Buffer層中。
具有相似到達間隔時間的讀寫任務促使調研團隊測試讀寫任務是否會背靠背執行，如果是這樣，這種的執行次序會持續多長時間。論文計算了每個檔案的連續讀和寫任務的平均次數（如圖4所示），并将分布情況繪制在圖5（b）中。
Figure 5(b): 平均連續讀任務數為13，平均連續寫任務數為3
超過80％的檔案經曆過2次或更多次連續讀任務，而超過65％的檔案經曆2次或更多次連續寫任務。大多數檔案經曆2次連續讀運作（65％）和2次連續寫運作（50％）。這表明檔案是在多次讀任務和多次寫任務的交替中進行通路的，這與前面觀察到RW檔案占總體的比例（71％）是一緻的。但是，許多檔案會經曆大量連續讀任務（由于RH檔案）。事實上，一個檔案經曆的平均連續讀任務的次數超過14，而平均連續寫任務的次數<4。讀任務的次數僅為寫任務次數的2.2倍（讀寫任務分類小節中提到），但是平均連續讀任務次數為連續寫任務次數的4.3倍。這表明對于大多數RW檔案而言，資料僅生産了幾次，然後被消耗了很多次。該觀察結果表明，科學模拟計算通常會在某些任務期間生成資料，然後在随後的幾次任務中将其用作驅動後續程式的輸入，以探索不同的潛在路徑或分析模拟現象。作者注意到，連續的寫任務并不意味着所有先前寫入的資料都被重寫或丢棄。一些科學工作流可能會在兩個連續的寫任務中追加資料，然後在後續任務中讀取該檔案的一部分用作分析。
發現4. HPC檔案平均經曆幾次連續的寫任務和一長串的連續讀任務。這個發現可以幫助利用MPI“hints”API來指導系統即将要執行的IO類型，以及對IO伺服器進行分區，以分别提供RH檔案（執行多次連續讀）和RW檔案（用于讀取和寫入任務），減少IO競争，進而提高IO性能。
多應用程式間的檔案共享特征。接下來的工作，為了将生産者與消費者的關系更進一步，進而了解生産者和消費者是相同的應用程式還是不同的應用程式。作者注意到所有通路同一個檔案的應用程式均由同一使用者運作。是以，對于任何檔案，生産者和使用者應用程式都屬于同一使用者。此外，由于權限問題，預設情況下，也不會将檔案在多個使用者之間共享。圖6（a）顯示了通路檔案的應用程式數量的CMF，超過67％的檔案被至少2個應用程式通路共同通路，表明檔案經常被多個應用程式共享。
Figure 6(a): 超過65%的檔案被至少兩個應用程式共享通路
圖6（b）展示出了對檔案執行IO的每個應用的到達間隔時間的CMF。每個應用程式的平均到達間隔時間為31小時，比單個讀任務的平均到達間隔時間（> 50小時）要低得多。是以，對于大多數檔案，有兩個或多個應用程式充當生産者和使用者，而不隻是被單個應用程式通路。這與作者的發現是一緻的：被多個應用程式通路的大多數檔案（86％）是RW檔案（這些共享檔案中隻有12％是RH檔案，隻有2％是WH檔案）。
Figure 6(b): 不同應用程式對同一個檔案執行IO操作的平均到達時間間隔為31小時
發現 5. HPC檔案由多個應用程式共享，并且每個應用程式都會執行讀取和寫入操作，同時充當生産者和使用者。這些任務的到達間隔時間還表明，生産者和消費者在時間上顯着分開，進而限制了跨應用程式通路時使用緩存的有效性。
IO資料通路特點
在檔案複用特點中，作者研究了如何在多次任務中使用相同的檔案。接下來，論文将分析在多次任務中資料通路特征會發生什麼樣的變化。圖6（c）顯示了每次通過讀任務和寫任務傳輸的資料量的CMF。可以觀察到，平均而言，每次讀任務傳輸17 GB的資料，而每次寫任務傳輸25 GB的資料，50％的讀任務傳輸資料量少于1 GB。
Figure 6(c) 平均每個讀/寫任務傳輸的資料量分别為17GB和25GB
發現6. 雖然讀任務比寫任務要多，且讀任務傳輸的資料總量大于寫任務，但是令人驚訝的是，單次寫任務所傳輸的資料量要單次讀任務要多。平均而言，每次寫任務運作的IO次數是讀任務的1.4倍。可以利用此發現來限制同時執行的寫任務數量，進而在系統級别更好地管理IO争用問題。回想一下先前的發現，HPC應用在一次任務中會主要傾向于隻執行一種類型的IO，是以，“寫任務”可以輕松地被檢測和分類，進而限制并發寫入的數量。
既然已經發現不同的任務會傳輸不同數量的資料，接下來要研究的問題是這種差異會如何影響後端OST。圖7顯示了在研究期間每個OST傳輸的标準化IO資料。
Figure 7: 每個OST傳輸的資料量存在很大差異，盡管檔案數量、應用數量和使用者數量總體是均衡的，平均每個讀/寫任務傳輸的資料量分别為17GB和25GB
有意思的是，每個OST傳輸多少資料有很大的不同。最不活躍的OST僅是最活躍OST的13％。另一方面，當檢視每個OST上的檔案數，使用這些檔案的應用程式數以及生成檔案的使用者數時，作者發現分布範圍要窄得多。
發現7. 對于在論文中研究的基于Lustre的系統，OST具有容量平衡的功能，以確定在檔案建立時的使用率大緻相等，但這并不能保證動态負載平衡。是以，在每個OST随時間推移觀察到的負載（資料傳輸）方面存在很大的不均衡，這也展現出動态檔案遷移（目前在Lustre檔案系統中并不支援），對隻讀檔案的副本及緩存（能讓IO負載得到分攤）的重要性。
接下來，作者研究變化的OST争用将如何影響各個并發運作的程序的IO時間，這些程序可能并行通路不同的OST。在此分析中，作者分别分析了Cori使用的三種不同的IO接口：POSIX 、MPI、和STD IO。首先，看一下使用每個接口傳輸的資料量。圖8（a）顯示POSIX是最常用的I / O接口，平均每次任務每個檔案傳輸大約260 GB資料，MPI接口平均每次任務每個檔案将傳輸約190 GB的資料。正如并行HPC應用程式所期望的那樣，STD是最不常用的接口。
Figure 8(a): POSIX和MPI接口承擔了絕大多數資料的傳輸任務
圖8（b）顯示了每次任務的單個程序上每個檔案執行IO傳輸資料量的标準差（标準差用于描述不同程序間資料傳輸的偏差）。平均而言，所有三個接口的标準差都非常小。例如，程序内POSIX IO執行的資料量傳輸的平均标準偏差小于1.5 GB，與使用POSIX傳輸的平均資料量（260 GB）相比可以忽略不計。
Figure 8(b): 在同一個應用程式内，不同程序間IO資料量偏差很小
另一方面，圖8（c）顯示了每次任務中單個程序内每個檔案執行IO時間的标準差（用于描述不同程序執行IO時間的波動情況）。對于使用POSIX接口執行的IO，此标準差特别高。這是因為通常在使用POSIX接口時，每個程序對不同的檔案執行IO，而在使用MPI IO接口時，所有程序對同一個共享檔案執行IO。因為Cori超級計算機上的預設條帶寬度為1，是以超過99％的檔案僅在1個OST上進行條帶化。是以，如果應用程式對多個檔案并行執行IO，因為檔案可能映射到不同的OST上，則這些應用很有可能對多個OST并行執行IO。是以，當使用POSIX IO時，這些OST上不同的資源争用級别會極大地影響各個程序的IO時間。
Figure 8(c): 各個程序在IO時間上的偏差很大
發現8. OST負載不平衡會導緻同時執行IO的程序所消耗的IO時間波動較大，尤其是當程序對不同的OST執行IO時（例如POSIX IO）。這導緻較快的程序必須等待較慢的程序完成，才能完成IO，然後才能繼續進行計算，進而浪費了HPC系統上寶貴的計算周期。
IO負載在不同時間上的波動。以前，研究人員們已經發現OST IO不平衡和争用會導緻單個任務的IO時間産生波動。下一步，論文探索的是IO負載在不同時間上的特性。圖9（a）顯示了一天中不同時間端傳輸的資料總量。可以觀察到，最密集的IO是由本地時間淩晨3點到淩晨5點之間開始的任務觸發的。
Figure 9(a): 淩晨3點到5點是資料IO的高峰期
值得注意的是，Cori的使用者遍布全球，是以特定的本地時間（即淩晨）不能訓示本地使用者何時最活躍，下面的分析不一定在不同因素之間建立直接的因果關系，而是嘗試解釋觀察到的趨勢。在圖9（b）中，展示了各個任務在一天中不同時段的IO耗時趨勢。縱軸是各個任務在指定時間段，針對同一個檔案執行IO所花費的時間與IO最長時間的比值（歸一化），進而友善在各個檔案之間進行标準化比較。由于淩晨3點到5點這段時間IO最為活躍，作者觀察到從淩晨3點到5點，以及淩晨5點之後的幾個小時，任務的IO耗時最長。盡管這個IO峰值時間段傳輸的資料最多，但相對來說，這段時間内任務的IO所花費的時間波動還是比較小的。
Figure 9(b): 淩晨3點到5點以及之後的幾個小時，對同一個檔案IO花費的時間最多
有意思的是，如圖9（c）顯示，盡管IO耗時的波動在全天所有時段内都非常高（> 20％），但在峰值IO期内開始的任務而言，IO耗時的波動反而最低。CoV（波動系數）是針對同一時刻開始的對同一檔案的任務進行計算的。IO波動CoV趨勢（圖9（c））與IO耗時趨勢圖幾乎相反（圖9（b））。實際上，IO耗時和IO的CoV的相關指數為-0.94，這表明兩者之間存在強烈的負相關性，也就是說，當IO活動最頻繁的時候，使用者可以預期的IO耗時變化反而會略低，即，如果使用者A每天在繁忙的IO活動期間開始相同的任務，與在IO活動不那麼頻繁的時間段啟動相同任務的使用者B相比，使用者A的任務IO耗時波動更小。當然，要權衡的是使用者A所花費的平均IO耗時要比使用者B長。這是因為當IO活動頻繁時，OST競争激烈，這可能會減慢所有IO，是以，IO耗時變化較小。但是，OST處于非競争狀态，并且IO更快時，IO耗時的波動趨勢就更加明顯。
Figure 9(c): 不同任務的IO耗時CoV在最繁忙的時間段反而最小
發現9.不同時段的IO負載不平衡會導緻同一任務的IO耗時在一天中的不同時段有所不同。而且，IO耗時的波動偏差在一天中的時段分布與IO耗時呈強烈的負相關性。這表明，HPC系統需要使用新的技術來降低各個任務中的IO耗時偏差（即同一應用程式的程序完成IO耗費時間偏差較大），因為目前IO耗時的偏差在全天所有時段内仍然較大（> 20％）。
不同任務的IO波動。接下來要解決的下一個問題是，如果存儲系統負載存在時間分布上的不平衡，是否會導緻IO耗時在不同任務上發生變化？在發現9中揭示的是同一時段内開始的任務中的IO波動。現在需要看看不論開始時間段如何，通路同一檔案的不同任務的IO波動。首先，作者探讨針對同一檔案，不同任務的資料傳輸量偏差。圖10（a）顯示了對于一個檔案，不同任務傳輸資料量CoV的CMF。總體而言，超過80％的檔案的CoV小于5％，這表明從不同任務的IO傳輸資料量的變化波動微不足道。RH檔案如此，RW檔案更是如此，同一個RW檔案在絕大多數情況下，都會被任務産生和消耗相似數量的資料。同一個WH檔案在不同任務中傳輸資料量的波動最大，平均CoV為35％。
圖10（b）顯示了每個檔案在不同任務中的IO耗時的CoV。針對所有檔案，即使不同任務間傳輸的資料量沒有顯着變化（上面的結論），但傳輸此資料所花費的時間卻存在很大的差異：兩次任務之間的IO耗時的平均CoV為39％。RH檔案在不同任務的IO時間偏差最大，平均CoV為68％，即使它們傳輸的資料量變化最小。這是由于以下事實造成的：由于時間負載不平衡，OST在不同時間段競争程度不同，由于讀任務平均傳輸的資料量少于寫任務（發現6中讨論的那樣），是以這種負載不平衡的影響在其任務的IO耗時上尤為突出，進而對RH的影響最大。
Figure 10: 針對同一檔案，不同任務對隻讀檔案傳輸資料量的偏最小（平均CoV 12%），但IO耗時偏差最大（平均CoV39%）
發現10. HPC檔案往往在不同任務中傳輸的資料量相似，但是就傳輸資料所花費的時間而言，它們的确存在很大差異。對于RH檔案而言，IO資料量的波動最小，但IO耗時波動最大，這意味着大家需要對RH檔案的IO耗時波動偏差投入更多關注和改善。
Cori特定環境和工作負載的影響。正如預期的那樣，論文的各個發現受到在美國國家能源研究科學計算中心（NERSC）和Cori在NERSC系統環境中執行的HPC負載的影響，仍然具有一定的局限性。是以，論文的發現不能照原樣推廣到所有HPC系統中，但是論文所描述的工作提供了一種方法論，可以在其他HPC中心進行類似性質的研究，進而優化HPC中的存儲系統。
我們認為，這篇論文的最大意義，并不在于其揭示了Cori中HPC負載的IO特點，而在于其描述了一種事實可行的調查IO模型及IO波動等特性的方法論。任何大型的HPC系統，都不是一蹴而就的，任何調優也不能是無根之水，隻有基于科學的調研和分析，才能做出最合理的優化和配置。