Jaki jest najszybszy system plików dla kompilacji programistów?

Przygotowuję system Linux, który będzie działał jako serwer kompilacji ciągłej integracji; głównie będziemy budować rzeczy w Javie, ale myślę, że to pytanie dotyczy dowolnego skompilowanego języka.

Jakiego systemu plików i ustawień konfiguracji powinienem użyć? (Na przykład wiem, że nie będę potrzebował na to czasu!) Serwer kompilacji poświęci dużo czasu na czytanie i pisanie małych plików oraz skanowanie katalogów w celu sprawdzenia, które pliki zostały zmodyfikowane.

AKTUALIZACJA: W tym przypadku integralność danych ma niski priorytet; to tylko maszyna do kompilacji ... końcowe artefakty zostaną spakowane i zarchiwizowane w innym miejscu. Jeśli system plików na komputerze kompilacji ulegnie uszkodzeniu i utraci wszystkie dane, możemy po prostu wyczyścić i ponownie zobrazować; kompilacje będą działać tak jak poprzednio.

Użyj ext4fs jako podstawowego systemu plików z kilkoma opcjami przyspieszenia, takimi jak

noatime,data=writeback,nobh,barrier=0,commit=300

Następnie union zamontuj na nim ramdysk tmpfs, aby pliki zapisane podczas kompilacji mogły korzystać z ramdysku. Zmień procedurę kompilacji, aby przenieść powstałe pliki binarne z tmpfs na końcu kompilacji lub scal tmpfs z powrotem w ext4fs przed odmontowaniem.

Najszybszy system plików? tmpfs zamontowany z dostępnej pamięci RAM, z noatimezestawem.

Jest to wykonalne tylko, jeśli masz procedurę sprawdzania wszystkiego, co jest potrzebne do zbudowania drzewa źródłowego (ponieważ zawartość systemu plików tmpfs zniknie po ponownym uruchomieniu) oraz jeśli źródło i obiekty zmieszczą się w rozsądnym rogu dostępnej pamięci RAM ( z wystarczającą ilością miejsca, aby uruchomić kompilator i linker bez zamiany). To powiedziawszy, nie możesz pobić pracy z pamięcią RAM dla szybkości.

Do odpowiedzi Michaela Dillona mogę dodać, że możesz stworzyć system plików ext4 z kilkoma opcjami:

mkfs.ext4 -O dir_index,extent -i 8096 /dev/<disk>


dir_index
    Use hashed b-trees to speed up lookups in large directories.

extent 
    Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead.  This is a  much  more  efficient  encoding  which  speeds  up filesystem access, especially for large files.

-i 8096 daje więcej i-węzłów na rozmiar, przydatne, ponieważ środowiska budowlane tworzą wiele plików.

W przypadku źródeł lepiej byłoby mieć obsługę kompresji w locie, którą jest Reiser4 lub Btrfs . Oba są jeszcze „nie do produkcji”, chociaż słyszałem o ludziach, którzy używają obu FS mocno i szczęśliwie. :-)

Następnym wyborem (zwykle to robię) jest Reiser3 , a nie Ext3 . Ext3 może być obecnie nieco szybszy, ale Reiser3 nie ma limitów czasu formatowania i-nodes, obsługuje zmianę on-line opcji „data =”. Obsługuje „ogon”, umożliwiając ściślejsze pakowanie małych plików, ale jeśli martwisz się szybkością, „notail”.

Zarówno XFS, jak i JFS byłyby kłopotliwe w przypadku „wielu małych plików”, szczególnie gdybyś ich potrzebował.

(Zapomniałem wspomnieć o EXT4: Tak, jest jeszcze szybszy niż EXT3. Ale wszystkie wyżej wspomniane ograniczenia EXT3 również są EXT4).

Opisane operacje dają kilka kluczowych wskazówek, co powinien zrobić idealny system plików:

• Masowo losowy dostęp r / w podczas procesu kompilacji.
• Wiele plików jest aktualizowanych w krótkiej kolejności, więc szybkie operacje na metadanych mają krytyczne znaczenie.
• Wydajna obsługa wielu małych plików w systemach plików o bardzo dużym obciążeniu.
• Wystarczająco dojrzały, aby nie ryzykować utraty danych w rzadkich i niejasnych przypadkach skrajnych.

Btrfs i Ext4 są trzema powyższymi, a czwarty jest wątpliwy. Ext4 jest prawdopodobnie wystarczająco dojrzały, ale btrfs jeszcze się nie skończył. noatimepomaga zwiększyć wydajność operacji na metadanych, ale gdy tworzysz mnóstwo nowych plików, nadal potrzebujesz operacji metadanych, aby krzyczeć szybko.

Właśnie wtedy podstawowa pamięć zaczyna być czynnikiem. Operacje metadanych XFS zwykle koncentrują się w kilku blokach, co może obciążać operacje. Systemy plików w stylu Ext są lepsze w przybliżaniu metadanych do danych, które opisują. Jeśli jednak pamięć jest wystarczająco abstrakcyjna (działasz w VPS lub jesteś podłączony do SAN) , nie ma to większego znaczenia .

Każdy system plików ma małe przyspieszenia, które można wykonać, aby uzyskać kilka punktów procentowych. To, jak wydajna jest podstawowa pamięć masowa, będzie miało duży wpływ na zysk, jaki zobaczysz.

Mówiąc wprost, jeśli masz wystarczająco dużo operacji we / wy w swoim magazynie, nieefektywność systemu plików zaczyna mieć mniejsze znaczenie. Jeśli używasz dysku SSD jako partycji kompilacji, wybór systemu plików jest mniej ważny niż to, z czym wygodniej jest pracować.

W przypadku wielu małych plików polecam Reiser zamiast ext3, xfs, jfs ..., chociaż słyszałem, że ext4 jest o wiele lepszy (tj. Przeciwny do tego, co mówi pauza) niż jego poprzednie wcielenia dla tego wzorca dostępu.

Reiser wypycha wiele struktur plików w drzewo i-węzłów - więc działa naprawdę dobrze w przypadku małych plików.

Jednak różnice w zachowaniu między wiodącymi systemami plików są stosunkowo niewielkie w porównaniu do korzyści, jakie uzyskasz dzięki wystarczającej ilości pamięci fizycznej do skutecznego buforowania / buforowania.

oraz skanowanie katalogów w celu sprawdzenia, które pliki zostały zmodyfikowane.

Jest to kiepski sposób rozwiązania problemu - mimo że jest stosunkowo prosty. Jeśli jest to tak ważne, pomyśl o napisaniu modułu obsługi inotify w celu zindeksowania modów.

OTOH, jeśli używasz dysku flash SSD (który da ci bardzo krótki czas wyszukiwania), zalecam użycie fs, który bardziej efektywnie dystrybuuje zapis z powodów długowieczności - np. JFFS2