aIOLi - Instytut Informatyki Teoretycznej i Stosowanej

aIOLi: planista operacji wejścia/wyjścia dla
wieloaplikacyjnych środowisk klastrowych∗
Przemysław Sowa
Wydział Inżynierii Mechanicznej i Informatyki
Kierunek Informatyka, Rok III
[email protected]
Streszczenie
Aplikacje rozproszone, szczególnie te intensywnie odczytujace
˛ lub zapisujace
˛
dane, cz˛esto odwołuja˛ si˛e do podsystemu wejścia/wyjścia w sposób niesekwencyjny.
Takie zachowanie znacznie zmniejsza wydajność dost˛epu do danych, dlatego wiele aplikacji używa bibliotek równoległego we/wy, jak np. ROMIO, aby kumulować
i reorganizować żadania.
˛
Tymczasem na klastrze cz˛esto uruchomionych jest kilka
aplikacji, które konkuruja˛ w dost˛epie do systemu we/wy, co niweczy optymalizacje dokonywane przez biblioteki. Projekt aIOLi stara si˛e optymalizować dost˛ep do
danych w środowiskach rozproszonych, jednocześnie b˛edac
˛ kompatybilnym z istniejacym
˛
oprogramowaniem, to znaczy nie wymagajac
˛ wprowadzania zmian w używanych aplikacjach.
1 Wst˛ep
Operacje we/wy od zawsze były waskim
˛
gardłem systemów komputerowych. Sytuacja
ta nie zmieni si˛e w najbliższym czasie, ponieważ wydajność urzadzeń
˛
pami˛eci masowej wzrasta znacznie wolnej niż procesorów czy pami˛eci operacyjnej. Ponadto, wraz ze
wzrostem wykorzystania klastrów i systemów wieloprocesorowych, rośnie liczba aplikacji (głównie naukowych), które wymagaja˛ od podsystemu we/wy przetwarzania ogromnej
liczby danych.
Jak pokazały liczne badania[5, 9] aplikacje równoległe, w odróżnieniu od np. baz
danych, które swoje działanie uzależniaja˛ od otrzymywanych zapytań, charakteryzuja˛
si˛e generowaniem przewidywalnych żadań
˛
we/wy. Niestety nawet jeżeli charakterystyka tych żadań
˛
jest znana, powoduja˛ one duży spadek wydajności, ponieważ zdalny serwer
sieciowego systemu plików otrzymuje duża˛ liczb˛e żadań
˛
różniacych
˛
si˛e znacznie przesu1
ni˛eciem . W rezultacie powoduje to duża˛ liczb˛e operacji pozycjonowania głowicy dysku,
które sa˛ najwolniejszymi operacjami we współczesnych systemach komputerowych (około 9ms).
∗
aIOLi to połaczony
˛
projekt pomi˛edzy Instytutem Informatyki Teoretycznej i Stosowanej na Politechnice Cz˛estochowskiej i Laboratoire ID w Grenoble (Francja): http://aioli.imag.fr
1 Przesuni˛
ecie (ang. offset) - to różnica mi˛edzy poczatkiem
˛
pliku (lub dysku), a poczatkiem
˛
danych, do
których kierowane jest żadanie.
˛
1
W zwiazku
˛
z tym, wielu naukowców próbowało stworzyć podsystem we/wy wydajnie radzacy
˛ sobie z tego typu żadaniami.
˛
Istniejace
˛ rozwiazania
˛
można podzielić na dwie
kategorie: równoległe systemy plików i biblioteki dla równoległego we/wy. Te pierwsze[3,
11, 12] staraja˛ si˛e znaleźć kompromis pomi˛edzy problemami rozproszonych danych (spójność, odporność na awarie, itp.), a optymalnym wykorzystaniem sprz˛etu. Natomiast biblioteki koncentruja˛ si˛e na aspektach równoległego we/wy i ograniczeniach zwiazanych
˛
z przenośnościa.˛ ROMIO[2], implementacja standardu MPI I/O[1], jest najbardziej znana˛
z nich.
Niemniej jednak, systemy te oferuja˛ zbyt duża˛ funkcjonalność, co utrudnia tworzenie
oraz użytkowanie aplikacji. Co wi˛ecej, wymagaja˛ one dogł˛ebnej znajomości udost˛epnianego interfejsu programowania oraz szczegółów wewn˛etrznej architektury, aby uzyskać
wysoka˛ wydajność.
Duża˛ wada˛ wspomnianych bibliotek jest fakt, że działaja˛ w kontekście jednej aplikacji. Kiedy na klastrze uruchomionych jest kilka aplikacji, optymalizacje żadań
˛
dokonywane przez każda˛ z nich wzajemnie si˛e wykluczaja,˛ powodujac
˛ znaczny spadek wydajności.
W takiej sytuacji jedynie podsystem we/wy ma globalna˛ wiedz˛e o żadaniach
˛
i może je
właściwie organizować. Niestety wi˛ekszość istniejacych
˛
równoległych systemów plików
nie oferuje odpowiednich mechanizmów szeregowania.
W pracy tej zaproponowano rozwiazanie
˛
omawianych problemów b˛edace
˛ złożeniem
dwóch elementów: przezroczystego mechanizmu agregowania żadań
˛
we/wy i algorytmu
szeregowania, dostosowanego do wymagajacych
˛
aplikacji równoległych. Te dwie cz˛eści
zostały połaczone
˛
w uniwersalnym szkielecie planowania we/wy, który działa jedynie na
serwerze, dzi˛eki czemu nie wymaga zmiany oprogramowania na całym klastrze.
Reszta pracy zorganizowana jest w nast˛epujacy
˛ sposób: sekcja 2 wprowadza do tematu szeregowania żadań
˛
we/wy, kolejna sekcja przybliża architektur˛e systemu aIOLi ,
a sekcja 4 charakteryzuje użyty algorytm planowania. W sekcji 5 omówiono oprogramowania używajace
˛ naszego systemu, natomiast kolejny fragment przedstawia wyniki
przeprowadzonych eksperymentów. Całość kończy si˛e podsumowaniem.
2 Strategie szeregowania we/wy
Istniejace
˛ algorytmy szeregowania we/wy można podzielić na dwie kategorie: dyskowe[14]
i równoległe[4, 8]. Te pierwsze staraja˛ si˛e minimalizować operacje przesuwania głowicy
dysku. Jednym z najnowszych algorytmów tego typu jest Anticipatory I/O scheduling[7],
używany domyślnie w Linuksie 2.6. Wykorzystuje on przewidujac
˛ a˛ heurystyk˛e, która faworyzuje żadania
˛
pochodzace
˛ od jednej aplikacji, potencjalnie należace
˛ do ciagłego
˛
obszaru dysku. Głównym minusem podobnych strategii jest to, że moga˛ prowadzić do głodzenia aplikacji, które nie generuja˛ żadań
˛
o zbliżonej lokalizacji. Przykładem strategii,
która stara si˛e być sprawiedliwa wobec wszystkich procesów konkurujacych
˛
o dost˛ep do
dysku jest Complete Fair Queuing[13], również dost˛epna w systemie Linux.
Ze wzgl˛edu na operowanie na niskim poziomie (urzadze
˛ ń dyskowych), algorytmy
tego rodzaju nie maja˛ dość informacji, aby wydajnie szeregować żadania
˛
pochodzace
˛ od
aplikacji rozproszonych.
Kategori˛e strategii równoległych stanowia˛ algorytmy b˛edace
˛ cz˛eścia˛ równoległych
systemów plików. Dystrybuuja˛ one operacje we/wy pomi˛edzy kilka serwerów, aby zminimalizować czas odpowiedzi i wykonać jak najwi˛ecej żadań
˛
równolegle, aczkolwiek nie
2
˛
jak również nie staraja˛ si˛e ich optybiora˛ one pod uwag˛e zależności pomi˛edzy żadaniami,
malizować.
3 Planista we/wy wysokiego poziomu
aIOLi różni si˛e znacznie od klasycznych planistów we/wy. Jest to uniwersalny szkielet
szeregowania, niezależny zarówno od medium pami˛eci masowej jak i podsystemu we/wy.
Oznacza to, że aIOLi może zostać dodany do wielu istniejacych
˛
systemów.
Oprogramowanie wykorzystujace
˛ aIOLi nazywamy klientem, może to być cały podsystem we/wy systemu operacyjnego, sieciowy system plików czy nawet pojedyncza aplikacja. Rysunek 1 przedstawia architektur˛e systemu aIOLi .
Pula
planistów
Kolejka żądań
Planista
Planista
Planista
...
...
...
Robotnik we/wy
Statystyki
i kontrola
Robonik we/wy
Robotnik we/wy
System aIOLi
Klient aIOLi 1
...
Klient aIOLi n
(sieciowy system plików)
(wirtualny system plików)
Podsystemy we/wy
Dysk
Dysk
Sieć
Rys. 1: Architektura systemu aIOLi
Klient przekierowuje otrzymywane żadania
˛
we/wy do aIOLi , który umieszcza je w
wewn˛etrznym systemie kolejkowania. Do każdego dysku przypisany jest osobny watek,
˛
zwany robotnikiem we/wy, który dokonuje szeregowania żadań
˛
według jednego z algorytmów planowania dost˛epnych w puli planistów, a nast˛epnie informuje klienta, wskazujac
˛
żadania
˛
wybrane do wykonania w bieżacej
˛ chwili. Algorytmy używane przez aIOLi różnia˛ si˛e znacznie od standardowych strategii szeregowania żadań
˛
we/wy wbudowanych w
systemy operacyjne, ponieważ nie operuja˛ na poziomie bloków (sektorów) ale na poziomie plików. W chwili obecnej aIOLi oferuje dwa algorytmy planowania: prosty, uwzgl˛edniajacy
˛ jedynie czas nadejścia żadania
˛
oraz algorytm MLF, opisany szerzej w kolejnej
sekcji.
4 Szeregowania żada
˛ ń we/wy na klastrze
Celem jest maksymalizacja całkowitej wydajności systemu, poprzez odpowiednia˛ reorganizacj˛e i agregacj˛e żadań,
˛
przy jednoczesnym zachowaniu sprawiedliwości wobec wszystkich aplikacji. Niestety wydajność, sprawiedliwość i czas odpowiedzi to cele wzajemnie
wykluczajace
˛ si˛e, dlatego aIOLi usiłuje si˛e znaleźć najlepszy kompromis pomi˛edzy nimi.
3
Podstawa˛ strategii omawianego systemu jest wariant algorytmu Multilevel Feedback
(MLF)[10]. Stara si˛e on optymalizować średni czas odpowiedzi jednocześnie zapobiegajac
˛ głodzeniu aplikacji poprzez oferowanie każdemu żadaniu
˛
indywidualnego kwantu
czasu, o zmiennej długości, przez który aplikacja uzyskuje wyłaczny
˛
dost˛ep do zasobu
(dysku).
Na potrzeby aIOLi algorytm ten został rozszerzony o mo żliwość agregowania żadań,
˛
a jego podstawowe kroki to:
1. nadchodzace
˛ żadania
˛
sa˛ sortowane wg. typu (zapis lub odczyt) i umieszczane w
dwóch odr˛ebnych kolejkach, dla każdego pliku,
2. każde żadanie
˛
otrzymuje poczatkowy
˛
kwant czasu równy zero,
3. dla każdej z kolejek przeprowadzana jest agregacja małych, ciagłych
˛
żadań
˛
w wi˛eksze, których kwant czasu jest suma˛ czasów żadań
˛
składowych,
4. kwant czasu każdego żadania
˛
jest zwi˛ekszany o pewna˛ stała,˛
5. wybierane jest pierwsze żadanie,
˛
którego przesuni˛ecie w pliku jest najmniejsze i
kwant czasu dość duży, aby zapewnić wykonanie,
6. powrót do kroku 1.
Dzi˛eki użyciu kwantów czasu algorytm ten jest kompromisem, ponieważ nie patrzy
jedynie na przesuni˛ecie w pliku danego żadania
˛
(wydajność), a dzi˛eki zwi˛ekszaniu porcji czasu w każdej rundzie (sprawiedliwość) nie faworyzuje jedynie małych żadań
˛
(czas
odpowiedzi).
5 Istniejacy
˛ klienci systemu aIOLi
Interfejs publiczny aIOLi jest bardzo prosty: składa si˛e z pi˛eciu funkcji. Pierwszy krok
każdego klienta, to wywołanie funkcji inicjalizujacej
˛ i przekazanie jako argumenty dwóch
funkcji zwrotnych. Pierwsza z nich b˛edzie wywołana przez aIOLi aby poinformować
klienta o wybranych żadaniach
˛
odczytu, natomiast druga o żadaniach
˛
zapisu. Opcjonalnie moga˛ być zarejestrowane dodatkowo funkcje, jak na przykład funkcja umożliwiajaca
˛
scalanie kilku żadań
˛
w jedno wi˛eksze. Kiedy klient otrzymuje nowe żadanie,
˛
zgłasza do
aIOLi : unikalny identyfikator pliku, typ żadania
˛
(odczyt lub zapis), przesuni˛ecie w pliku
oraz długość. Robotnicy we/wy b˛eda˛ wywoływali planist˛e na podstawie tych informacji. Dzi˛eki tak zwi˛ezłemu interfejsowi łatwo jest rozszerzyć istniejace
˛ oprogramowanie o
aIOLi .
Jak dotad
˛ powstało dwóch klientów. Pierwszy to ulepszony serwer sieciowego systemu plików - NFS, oparty na kodzie z jadra
˛ systemu Linux w wersji 2.6.15. Drugi klient
to rozszerzenie dla wirtualnego systemu plików (VFS) Linuksa, służace
˛ poprawie wydajność wszystkich operacji we/wy w systemie. Oba moduły dost˛epne sa˛ wraz ze standardowa˛ dystrybucja˛ systemu aIOLi 2 . Ze wzgl˛edu na ograniczona˛ obj˛etość tej pracy,
omówione zostana˛ jedynie eksperymenty z serwerem NFS.
2 http://aioli.imag.fr
4
5.1 Serwer NFS
Mimo że NFS nie był projektowany jako system plików dla klastrów, jak również nie
jest on najwydajniejszy to jednak wcia˛ż pozostaje podstawowym sposobem współdzielenia informacji w środowiskach klastrowych. W tym kontekście serwer musi radzić sobie
z ogromna˛ ilościa˛ równoczesnych żadań,
˛
które pochodza˛ od uruchomionych procesów.
Dodatkowo żadania
˛
te nie maja˛ żadnego uporzadkowania.
˛
Standardowy planista we/wy
systemu Linux ciagle
˛ przełacza
˛
si˛e pomi˛edzy plikami, powodujac
˛ duża˛ liczb˛e operacji
pozycjonowania głowicy dysku. W rezultacie ogólna wydajność jest bardzo niska[6]. Sa˛
to idealne warunki, aby przetestować rozwiazanie
˛
takie jak aIOLi .
Oryginalny serwer NFS przetwarza żadania
˛
natychmiast po ich nadejściu. Zmodyfikowana wersja zmienia to zachowanie w przypadku żadań
˛
odczytu lub zapisu, które sa˛
zgłaszane do aIOLi , a serwer czeka na przyjście kolejnych. Kiedy aIOLi wybierze jakieś
żadania
˛
do wykonania informuje o tym serwer NFS, który je przetwarza. Ta niewielka
zmiana zaowocowała dużym wzrostem wydajności w przypadku aplikacji równoległych,
co można zobaczyć w sekcji 6.1.
5.2 Rozszerzenie wirtualnego systemu plików Linuksa
Moduł ten jest umieszczony pomi˛edzy interfejsem wywołań systemowych, a wirtualnym
systemem plików. Tak jak w przypadku serwera NFS, modyfikuje on zachowanie dla
operacji odczytu lub zapisu. Wszystkie takie żadania
˛
sa˛ analizowane przez aIOLi w celu
wyznaczenia optymalnego momentu ich wykonania.
6 Eksperymenty
Testy przeprowadzane były na klastrze b˛edacym
˛
cz˛e ścia˛ gridu Grid50003 . Każdy w˛ezeł
to IBM eServer 325, posiadajacy
˛ dwa procesory AMD Opteron 2GHz, 2GB RAM i dysk
twardy o pojemności 80GB, którego przepustowość została oszacowana przez program
hdparm na 57MB/s. Klaster połaczony
˛
jest siecia˛ Gigabit Ethernet, wszystkie w˛ezły pracowały pod kontrola˛ systemu Debian GNU/Linux z jadrem
˛
2.6.12. Jeden z komputerów
pełnił rol˛e serwera NFS (wersja 3, TCP, rozmiar bufora odczytu zapisu ustawiony na
32KB, pami˛eć podr˛eczna została wyłaczona)
˛
i eksportował partycj˛e z systemem plików
ext3.
6.1 IOR
I/O Stress Benchmark Codes4 to benchmark dla równoległych systemów plików opracowany w ramach projektu Scalable I/O w Lawrence Livermore National Laboratory. Ten
program równoległy dokonuje operacji odczytu i zapisu danych używajac
˛ standardowych
funkcji we/wy (POSIX) lub biblioteki MPI-IO i informuje o uzyskanej przepustowości.
Przeprowadzony eksperyment polegał na uruchomieniu programu IOR na 32 procesorach, znajdujacych
˛
si˛e na 16 fizycznych w˛ezłach. Rozmiar pliku został ustawiony na 4GB,
3 http://www.grid5000.fr
4 http://www.llnl.gov/asci/purple/benchmarks/limited/ior/
5
70
POSIX
MPI−IO
aIOLi
Przepustowość [MB/s]
60
50
40
30
20
10
0
8
16
32
64
128
Ziarnistość [KB]
512
1024
4096
Rys. 2: Test odczytu
32 procesy IOR na 16 w˛ezłach.
70
POSIX
MPI−IO
aIOLi
Przepustowość [MB/s]
60
50
40
30
20
10
0
8
16
32
64
128
512
Ziarnistość [KB]
1024
4096
Rys. 3: Test zapisu
32 procesy IOR na 16 w˛ezłach.
a ziarnistość operacji rosła od 8KB do 4MB. Porównywana była wydajność interfejsu POSIX oraz MPI-IO przy użyciu oryginalnego serwera NFS, a nast˛epnie test powtórzono dla
serwera rozszerzonego o aIOLi .
Wykres 2 przedstawia wydajność odczytu danych, jak łatwo zauważyć, aIOLi zapewnia najlepsze wyniki. Dla ziarnistości do 32KB zmodyfikowany serwer NFS zapewnia przepustowość, która równa jest fizycznym możliwościom dysku twardego. Wraz ze
wzrostem ziarnistości wydajność zaczyna spadać, jednak nadal wyraźnie dystansuje standardowy interfejs POSIX oraz bibliotek˛e MPI-IO. Spadek przepustowości wynika z zachowania klientów NFS, którzy żadania
˛
wi˛eksze niż 32KB dziela˛ na fragmenty po 32KB.
Dla przykładu, żadanie
˛
o wielkości 4MB zostanie podzielone na 128 żadań
˛
o rozmiarze
32KB. Ponieważ na każdej maszynie uruchomione sa˛ dwa procesy IOR, to w tej sytuacji
do wysłania b˛edzie 256 (już podzielonych) żadań.
˛
Należy zwrócić uwag˛e na fakt, że za
komunikacj˛e w protokole NFS odpowiedzialna jest warstwa RPC, która jest niezależna
i działa w sposób globalny dla systemu. Warstwa ta stara si˛e być sprawiedliwa wobec
wszystkich obsługiwanych aplikacji, dlatego wysyła za każdym razem po jednym komunikacie każdej z nich. Oznacza to, że za pierwszym razem wysłane zostanie pierwsze ze
6
70
POSIX
MPI−IO
aIOLi
Przepustowość [MB/s]
60
50
40
30
20
10
0
4
8
16
32
64
128
Ziarnistość [KB]
512
1024
4096
Rys. 4: „Izolowany” test zapisu
32 procesy IOR na 32 w˛ezłach.
128 żadań
˛
pierwszego procesu IOR, natomiast zaraz potem pierwsze ze 128 żadań
˛
drugiego procesu IOR. W rezultacie serwer otrzyma dwa żadania,
˛
odwołujace
˛ si˛e do danych
oddalonych od siebie o 4MB, a w sumie (dla 32 procesów IOR) b˛eda˛ to 32 rozłaczne
˛
ża˛
dania. W tej sytuacji żaden planista nie uniknie wielu kosztownych operacji przesuni˛ecia
głowicy dysku, a co za tym idzie spadku wydajności.
Wykresy 3 i 4 prezentuja˛ wydajność zapisu danych. Na pierwszym z nich widać, że
MPI-IO zapewnia lepsza˛ przepustowość niż aIOLi dla ziarnistości poniżej 64KB. Dzieje
si˛e tak głównie ze wzgl˛edu na problem z warstwa˛ RPC (opisany w poprzednim akapicie),
natomiast MPI-IO unika tego zjawiska dzi˛eki mechanizmowi synchronizacji. Aby to udowodnić powtórzono ten test, ale tym razem na 32 w˛ezłach, co oznacza, że każdy proces
IOR był niezależny. Uzyskane wyniki prezentuje wykres 4, tutaj aIOLi majac
˛ pełen obraz
generowanych żadań
˛
jest w stanie zapewnić optymalna˛ wydajność.
7 Podsumowanie
W pracy tej zaprezentowano aIOLi, szkielet planowania dla wieloaplikacyjnych środowisk rozproszonych, w których wymagana jest wysoka wydajność operacji we/wy. Podkreślono główne cechy systemu, stanowiace
˛ o jego sile: przezroczystość dla aplikacji
(aIOLi znajduje si˛e pomi˛edzy programem a podsystemem we/wy), maksymalizowanie
przepustowości poprzez dobrze zaprojektowany algorytm szeregowania oraz zachowanie
sprawiedliwości dzi˛eki wykorzystaniu kwantów czasu.
Omawiany system został sprawdzony w praktyce przy u życiu znanego benchmarku
IOR, a otrzymane wyniki potwierdziły wysoka˛ wydajność proponowanego rozwiazania.
˛
Okazało si˛e, że operacje zapisu sprawiaja˛ pewne problemy, które powinny być rozwiazane
˛
w przyszłości. Jedna z propozycji to użycie aIOLi również na w˛ezłach obliczeniowych,
aby zapobiec niekorzystnemu funkcjonowaniu mechanizmu RPC.
Interesujac
˛ a˛ perspektywa˛ jest dodanie aIOLi do innych sieciowych systemów plików,
takich jak np. Lustre czy GPFS. W najbliższym czasie planowana jest integracja z równoległa˛ wersja˛ NFS w ramach projektu NFSp 5 . Biorac
˛ pod uwag˛e dobre wyniki zarówno
5 http://nfsp.imag.fr
7
aIOLi jak i NFSp istnieje szansa stworzenia systemu kompatybilnego z istniejacym
˛
oprogramowaniem, a osiagami
˛
dorównujacego
˛
najlepszym, kosztownym rozwiazaniom.
˛
Literatura
[1] MPI I/O.
http://hpcf.nersc.gov/software/libs/io/mpiio.html.
[2] ROMIO.
http://www-unix.mcs.anl.gov/romio/.
[3] P. H. Carns, W. B. Ligon III, R. B. Ross, and R. Thakur. PVFS: A parallel file system for
linux clusters. In Proceedings of the 4th Annual Linux Showcase and Conference, pages
317–327, Atlanta, GA, October 2000. USENIX Association.
[4] F. Chen and S. Majumdar. Performance of parallel i/o scheduling strategies on a network of
workstations. Eighth International Conference on Parallel and Distributed Systems, 2001.
[5] P. E. Crandall, R. A. Aydt, A. A. Chien, and D. A. Reed. Input/output characteristics of scalable parallel applications. In Proceedings of Supercomputing ’95, San Diego, CA, December
1995. IEEE Computer Society Press.
[6] D. Ellard and M. Seltzer. NFS tricks and benchmarking traps.
[7] S. Iyer and P. Druschel. Anticipatory scheduling: A disk scheduling framework to overcome
deceptive idleness in synchronous I/O. In 18th ACM Symposium on Operating Systems
Principles, Oct. 2001.
[8] R. Jain, K. Somalwar, J. Werth, and J. C. Browne. Heuristics for scheduling I/O operations.
IEEE Transactions on Parallel and Distributed Systems, 8(3):310–320, March 1997.
[9] N. Nieuwejaar, D. Kotz, A. Purakayastha, C. S. Ellis, and M. Best. File-access characteristics
of parallel scientific workloads. IEEE Transactions on Parallel and Distributed Systems,
7(10):1075–1089, October 1996.
[10] K. Pruhs, J. Sgall, and E. Torng. Online scheduling. In Hanbook of Scheduling, chapter 15.
CRC Press, 2004.
[11] R. L. F. B. Schmuck. Gpfs: A shared-disk file system for large computing clusters. In
Proceedings of the 5th Conference on File and Storage Technologies, January 2002.
[12] P. Schwan. Lustre : Building a file system for 1,000-node clusters. In Proceedings of the
Linux Symposium, Ottawa, July 2003.
[13] S. Seelam, R. Romero, P. Teller, and B. Buros. Enhancements to linux I/O scheduling. In
Proceedings of the Linux Symposium 2005, volume 2, pages 175–192, July 2005.
[14] M. Seltzer, P. Chen, and J. Ousterhout. Disk scheduling revisited. In Proceedings of USENIX,
pages 313–323, 1990.
8