Grupy alokacji XFS: jak w pełni wykorzystać wydajność systemów NVMe

XFS NVMe w pełni ujawnia swój potencjał dopiero wtedy, gdy konsekwentnie dostosowuję grupy alokacji, rozmiary bloków, opcje montowania oraz harmonogram operacji we/wy do właściwości nowoczesnych dysków SSD NVMe. W niniejszym artykule pokazuję konkretnie, w jaki sposób planuję, formatuję i obsługuję system plików XFS na dyskach NVMe, tak aby równoległość grup alokacji (AG), optymalizacja dziennika (log tuning) oraz głębokość kolejki sprzętowej zapewniały wymierną przepustowość i niskie opóźnienia.

Punkty centralne

• AG-Design: Należy wybrać wystarczającą liczbę grup alokacji, aby zapewnić równoległość, ale bez nadmiernego obciążenia procesora.
• Rozmiar bloku: Powiązanie bloków systemu plików z fizycznymi sektorami 4K w celu uniknięcia wielokrotnego dostępu.
• Dostrajanie mocowania: celowe połączenie parametrów noatime, allocsize, logbufs/logbsize zamiast wartości domyślnych.
• harmonogram: Przetestować i ustalić wartość „none“ lub „mq‑deadline“ w zależności od docelowych wartości opóźnienia.
• Obciążenia: Skonfigurować bazę danych, streaming i AI-Scratch z odpowiednią liczbą AG oraz funkcją readahead.

Dlaczego grupy alokacji przyspieszają działanie NVMe

Grupy alokacji dzielą wolne bloki, i-węzły i drzewa B+ na niezależne od siebie obszary, dzięki czemu wiele wątków może pracować jednocześnie i Zamki rzadziej sięgają. Właśnie taki podział pasuje do NVMe, które dzięki wielu kolejkom i głębokiej równoległości obsługuje żądania jednocześnie, ograniczając w ten sposób konflikty bloków. W praktyce przekładam równoległość sprzętową na wystarczającą liczbę zadań, co pozwala na równoległą alokację i szybką aktualizację metadanych, co z kolei wygładza szczyty opóźnień. Jednym z Porównanie wydajności Analiza systemów plików często pokazuje, jak XFS radzi sobie przy dostępie równoległym, podczas gdy obciążenia sekwencyjne nadal działają niezawodnie. Ważna pozostaje jednak równowaga: zbyt mała liczba grup roboczych ogranicza równoległe alokacje, a zbyt duża – powoduje zauważalne spowolnienie czas procesora.

Określenie liczby i wielkości grup roboczych

Podczas formatowania celowo ustalam liczbę AG, zazwyczaj w przedziale od kilkudziesięciu do 64–128 AG na terabajt, aby zapewnić wystarczający poziom równoległości bez nadmiernego nakładu pracy administracyjnej oraz aby Równoległość wykorzystać. Z mkfs.xfs -f -d agcount=64 /dev/nvme0n1 wyraźnie określam rozkład; za pomocą -d rozmiar= Alternatywnie można regulować liczbę grup roboczych (AG). W przypadku obciążeń zawierających wiele małych plików wybieram raczej większą liczbę grup, a w przypadku dużych strumieni sekwencyjnych nieco mniej, aby utrzymać obciążenie procesora pod kontrolą. Unikam skrajnych wartości, ponieważ bardzo mała liczba AG powoduje duże obciążenie administracyjne podczas zapełniania systemu plików. Najważniejsze pozostaje to, że kieruję się pojemnością, wyposażeniem w pamięć RAM oraz typową charakterystyką operacji wejścia/wyjścia, aby alokacje były równomiernie rozłożone na koła zainteresowań rozsypywać.

Prawidłowe powiązanie rozmiarów bloków ze sprzętem

Wiele dysków SSD NVMe wewnętrznie obsługuje sektory 4K, nawet jeśli zewnętrznie oferują one rozmiar 512 bajtów, dlatego ustawiam rozmiar bloku systemu plików na 4096 bajtów, zmniejszając w ten sposób liczbę wewnętrznych cykli odczytu-modyfikacji-zapisu dla Dostęp do zapisu. Podczas formatowania używam na przykład mkfs.xfs -f -b size=4096 /dev/nvme0n1, jeśli fizyczny rozmiar sektora wynosi 4K. Nieprawidłowo wyrównany system plików generuje niepotrzebne dodatkowe operacje wejścia/wyjścia, co odczuwalnie spowalnia działanie, zwłaszcza w przypadku losowych, niewielkich operacji zapisu. Odpowiedni rozmiar bloku zapewnia spójność operacji dostępu, wyrównuje opóźnienia i zapewnia lepszą wydajność IOPS przy krótkich zapytaniach. W szczególnych przypadkach, gdy wykonywane są bardzo duże zadania sekwencyjne, łączę bloki 4K z większym readahead, aby Przepustowość wzrasta.

Opcje montażu dla obciążenia NVMe

Nawet bez optymalizacji system plików XFS działa już sprawnie, jednak odpowiednio dobrane opcje montowania pozwalają jeszcze bardziej zwiększyć wydajność i uniknąć niepotrzebnych aktualizacji metadanych Obciążenie odczytem. Aktywuję noatime,nodiratime, w zależności od obciążenia ustaw większą allocsize (np. 64M) i zwiększ bufor dziennika o logbufs=8,logbsize=256k w celu zwiększenia przepustowości metadanych. Zamiast odrzucić na Mount prowadzę fstrim okresowo, aby polecenia TRIM były wykonywane zbiorczo. Przykładowy wiersz w /etc/fstab wygląda następująco: /dev/nvme0n1 /data xfs noatime,nodiratime,allocsize=64m,logbufs=8,logbsize=256k 0 0. Poniższa tabela przedstawia powiązania między popularnymi opcjami a ich efektami oraz typowymi zastosowaniami, co pozwala mi szybciej podejmować decyzje i Konfiguracja udokumentuj.

Opcja	Efekt	Kiedy używać
noatime,nodiratime	Ogranicza liczbę operacji zapisu metadanych podczas dostępu	Duża liczba odczytów, obciążenia związane z siecią i analizą danych
allocsize=64m	Grupuje przydziały, ogranicza fragmentację	Duże sekwencyjne strumienie zapisu
logbufs=8	Więcej równoległych buforów logów dla metadanych	Obciążenie transakcyjne, wiele drobnych aktualizacji
logbsize=256k	Większe bloki do zapisywania logów	Wyższa przepustowość metadanych
brak odrzucić	Pozwala uniknąć kosztów związanych z synchronicznym TRIM-em	Zamiast tego regularne fstrim

Harmonogramy wejścia/wyjścia: none, mq-deadline i inne.

Kontrolery NVMe same efektywnie porządkują żądania, dlatego często korzystam z brak najlepiej i w ten sposób utrzymaj Nad głową niskie. W przypadku obciążeń o rygorystycznych wymaganiach dotyczących opóźnień testuję mq-deadline, ponieważ może to stabilizować czasy odpowiedzi, nawet jeśli maksymalna przepustowość nieznacznie spadnie. Podczas gdy bfq choć wyróżnia się pod względem interaktywności, rzadko jest pierwszym wyborem w przypadku serwerowych dysków NVMe. Decyzję podejmuję dopiero po przeprowadzeniu pomiarów za pomocą fio, które mierzą IOPS, przepustowość i opóźnienie oddzielnie dla operacji odczytu/zapisu oraz losowych/sekwencyjnych. Szczegóły dotyczące rozważenia poszczególnych opcji omówię bardziej szczegółowo w tym zwięzłym Przewodnik po harmonogramie we/wy, zanim wprowadzę to ustawienie do środowiska produkcyjnego.

Precyzyjne dostosowywanie obciążeń

Bazy danych z dużą liczbą operacji commit zyskują na umiarkowanej liczbie AG oraz zorientowanych blokach 4K, noatime i podniesionym logbsize, aby transakcje związane z metadanymi przebiegały sprawnie. Zadania analityczne i potoki strumieniowe realizuję z większą allocsize oraz większe wyprzedzanie odczytu przy wysokiej przepustowości sekwencyjnej. W przypadku danych roboczych AI/ML i dużej liczby równoległych procesów roboczych wolę raczej wybrać większą liczbę grup roboczych, noatime, skonsolidowane alokacje oraz brak jako harmonogram. Kopie zapasowe lub operacje archiwizacji zyskują dodatkowo dzięki okresowemu fstrim, aby odciążyć mechanizm SSD Garbage Collection. Każde dostosowanie weryfikuję za pomocą powtarzalnych serii pomiarów, zanim Ustawienia domyślne na stałe zastąpię.

Szybka interpretacja typowych objawów

Jeśli system plików XFS wyświetla komunikat „No space left on device“ pomimo widocznej wolnej przestrzeni, często oznacza to, że wyczerpała się pojemność pojedynczego segmentu (AG), dlatego zalecam rozłożenie danych, agcount i sprawdzam wolne obszary metadanych. Nieoczekiwanie wysokie opóźnienie przy niewielkich operacjach losowego zapisu interpretuję zazwyczaj jako oznakę nieodpowiedniego wyrównania bloków, zbyt małych allocsize lub zbyt częste aktualizacje metadanych. W takich przypadkach pomocne są bloki 4K, większe przydziały pamięci oraz noatime, aby zgrupować operacje zapisu. Jeśli obciążenie procesora w systemie plików wyraźnie wzrośnie, być może wybrano zbyt dużą liczbę grup (AG), zwłaszcza gdy system plików jest prawie zapełniony. W takim przypadku zmniejszam liczbę grup podczas ponownego formatowania lub powiększam partycję, aby Administracja obniżyć.

Przegląd parametrów – szybki przegląd

W przypadku powtarzających się konfiguracji mam pod ręką krótką listę kontrolną, którą sprawdzam przed każdym formatowaniem i w ten sposób Constance które przekładają się na wyniki. Najpierw sprawdzam fizyczny rozmiar sektora, głębokość kolejki oraz funkcje kontrolera urządzeń NVMe. Następnie ustalam liczbę grup agregatów (AG) lub ich rozmiar i dostosowuję rozmiar bloku do 4K. Następnie definiuję opcje montowania dostosowane do obciążenia i planuję okresowe fstrim. Na koniec testuję różne warianty harmonogramów operacji wejścia/wyjścia i dokumentuję najszybszą kombinację dla danego przypadku zastosowania.

Stopniowe planowanie wdrożenia nowego systemu plików XFS na dyskach NVMe

Na początku ustalam pojemność, fizyczny rozmiar sektora, typowe rozmiary plików oraz liczbę równoległych wątków, aby Planowanie AG rozpoczynam od solidnego przygotowania. Następnie formatuję dysk, ustawiając odpowiednią liczbę AG, rozmiar bloku 4K oraz opcjonalne parametry i-nodów, jeśli spodziewam się dużej liczby małych plików. W kolejnym kroku montuję dysk za pomocą noatime, bardziej odpowiedni allocsize oraz zoptymalizowanymi parametrami dziennika i sprawdzam wyniki za pomocą fio. Następnie następuje wybór harmonogramu, przy czym ja brak oraz mq-deadline porównuję, zwracając przy tym uwagę zarówno na IOPS, jak i na opóźnienie. Na koniec wdrażam system monitorowania i planowane fstrim, aby zapewnić wydajność w perspektywie długoterminowej stały pozostanie bez zmian i nie pojawią się żadne niespodzianki.

Zastosowanie w środowiskach hostingowych

W scenariuszach hostingu z wykorzystaniem kontenerów, stosów internetowych i baz danych starannie zaplanowana konfiguracja systemu plików XFS przekłada się bezpośrednio na czas odpowiedzi oraz Przepustowość . Biorę przy tym pod uwagę głębokość kolejki oraz liczbę równoległych procesów roboczych, aby w sensowny sposób połączyć liczbę grup roboczych i harmonogram. Szczegółowe wyjaśnienie, dlaczego długość kolejki na dysku NVMe wyznacza tempo pracy, przedstawiłem w artykule na temat Głębokość kolejki opracowałem. W przypadku mikrousług przetwarzających duże ilości danych często zwiększam readahead, grupuj przydziały i mierz wyniki iteracyjnie po każdej zmianie. Użytkownicy korzystający z wydajnych serwerów zarządzanych lub serwerów root zyskują w ten sposób na niskim opóźnieniu, wysokim stopniu równoległości oraz łatwości planowania pracy na XFS.

Reflink, i-węzły i funkcje związane z metadanymi – świadomy wybór

Podczas formatowania sam decyduję, czy CoW/Reflink ma sens w moim przypadku. Za pomocą mkfs.xfs -m reflink=1 Włączam funkcje „Copy-on-Write” i „szybkie klony”, co pozwala zaoszczędzić miejsce i czas podczas tworzenia wielu kopii, obrazów maszyn wirtualnych lub artefaktów kompilacji. W przypadku baz danych o dużym obciążeniu zapisem wyłączam Reflink (reflink=0), aby zmniejszyć obciążenie związane z metadanymi i ograniczyć ilość wpisów w dzienniku. Ponadto sprawdzam finobt (Free‑Inode‑B‑Tree), który przyspiesza procesy alokacji w przypadku wielu i-węzłów i który w aktualnych narzędziach jest zazwyczaj domyślnie włączony.

Die Rozmiar i-węzła decyduję o -i rozmiar=. W przypadku obciążeń zawierających wiele atrybutów rozszerzonych (ACL, SELinux, metadane aplikacji) wybieram 512 lub 1024 bajtów, aby atrybuty częściej mieściły się w i-nodzie i nie trafiały do oddzielnych bloków. Przykład: mkfs.xfs -f -b size=4096 -i size=512 /dev/nvme0n1. Większe i-węzły zajmują nieco miejsca, ale pozwalają zaoszczędzić na liczbie operacji dostępu, gdy metadane są często odczytywane lub zapisywane. Funkcje takie jak bigtime zwiększają zakres obsługiwanych znaczników czasu w nowoczesnych systemach i sprawdzają się w nowych instalacjach, nie powodując zauważalnego spadku wydajności. W przypadku opcjonalnych struktur, takich jak rmapbt Zazwyczaj rezygnuję z nich w przypadku woluminów przeznaczonych wyłącznie do pomiaru wydajności, ponieważ choć przede wszystkim zwiększają one łatwość zarządzania i weryfikacji, to jednocześnie powodują dodatkowy nakład pracy.

Dziennik zewnętrzny, rozmiar dziennika i wyrównanie pasm

W przypadku obciążeń generujących duże ilości metadanych warto zastosować oddzielne urządzenie do rejestrowania (dziennik) na drugim dysku NVMe o bardzo niskim opóźnieniu, aby zminimalizować konflikt między danymi użytkowymi a zapisem do dziennika. Stosuję to podczas formatowania za pomocą -l logdev=/dev/nvme1n1,size= i dostosuj rozmiar dziennika tak, aby fazy szczytowego obciążenia nie powodowały ciągłego uruchamiania funkcji Log-Force (często 1–4 GiB, w zależności od wzorca transakcji). W połączeniu z logbufs/logbsize W środowisku Mount zewnętrzny dziennik znacznie stabilizuje czasy transakcji, gdy pojawia się wiele małych plików lub aktualizacji metadanych.

Jeśli dysk NVMe znajduje się za macierzą RAID lub modułem Device-Mapper, dostosowuję system plików XFS do rozmiarów pasm, tak aby operacje zapisu dokładnie pokrywały granice pasm. Odbywa się to podczas formatowania za pomocą -d su=,sw=. Następnie sprawdzam te wartości za pomocą xfs_info /mount. Ważne: parametrów tych nie da się później zmienić bez ponownego sformatowania. W przypadku pojedynczego dysku NVMe bez stripingu na niższym poziomie pozostawiam automatyczne dostrajanie systemowi XFS.

Zapewnienie wyrównania partycji i bloków

Przed sformatowaniem tworzę partycje wyrównane co 1 MiB, aby bloki systemu plików dokładnie pokrywały się z fizycznymi granicami 4K. Za pomocą parted -a optimal lub odpowiednią konfiguracją GPT zapobiegam niepożądanym przesunięciom. Rzeczywisty fizyczny i logiczny rozmiar sektora weryfikuję za pomocą cat /sys/block/nvme0n1/queue/physical_block_size oraz logical_block_size. Dopiero gdy ta podstawa jest odpowiednia, bloki 4K i porcje alokacji osiągają pełną skuteczność.

Sterowanie bezpośrednim wejściem/wyjściem (Direct I/O), pamięcią podręczną stron (Page Cache) i mechanizmem zapisu z opóźnieniem (Writeback)

W przypadku baz danych i strumieni logów, które samodzielnie zarządzają własną pamięcią podręczną, celowo stosuję O_DIRECT, aby uniknąć podwójnego buforowania w pamięci podręcznej stron. System plików XFS wykazuje w tym zakresie bardzo dobrą skalowalność, o ile nie buforuję jednocześnie tych samych plików w trybie mieszanym i nie zapisuję ich bezpośrednio. W przypadku obciążeń strumieniowych wyższa readahead przepustowość: blockdev --setra 4096 /dev/nvme0n1 (co odpowiada 2 MiB) to praktyczna wartość początkowa, którą mierzę i w razie potrzeby dostosowuję z większą precyzją.

Aby zachować równowagę systemu, ostrożnie dostosowuję progi writeback. Zamiast wartości procentowych stosuję wartości liczbowe, aby w przypadku dużych konfiguracji pamięci RAM nie gromadzić zbyt dużej ilości danych brudnych. Przykład (należy testować z rozwagą):

sysctl -w vm.dirty_background_bytes=268435456
sysctl -w vm.dirty_bytes=2147483648

W ten sposób zapobiegam długim falom flush, które zwiększają opóźnienia. Dokumentuję te ustawienia dla każdego hosta, aby można je było odtworzyć i aby nie zostały niezauważenie nadpisane przez domyślne ustawienia dystrybucji.

Wykorzystanie topologii kolejki i procesora

NVMe wykorzystuje wielokolejowe operacje wejścia/wyjścia: zazwyczaj dla każdego rdzenia procesora istnieją osobne kolejki sprzętowe, dzięki czemu nie pozostawiam podziału sygnałów IRQ i przypisania do procesora przypadkowi. Uruchomiony irqbalance to wartość bazowa; w szczególnych przypadkach związanych z opóźnieniami ustawiam przerwania NVMe za pomocą /proc/irq/*/smp_affinity ukierunkowane na rdzenie położone w pobliżu NUMA. cat /sys/block/nvme0n1/queue/scheduler pokaż mi aktywny harmonogram, nr_zapytania oraz rq_affinity wpływają na sposób rozdzielania zleceń między kolejki. W przypadku bardzo zrównoleglonych procesów roboczych zwiększam eksperymentalnie /sys/block/nvme0n1/queue/nr_requests umiarkowanie, aby lepiej amortyzować szczytowe wartości, nie przeciążając przy tym sterownika.

Ponadto mogę precyzyjnie regulować grupowanie przerwań urządzeń NVMe (funkcja kontrolera). Umiarkowane zwiększenie parametrów grupowania pozwala wyrównać obciążenie IRQ, nie może jednak spowodować przekroczenia docelowych wartości opóźnień. Takie zmiany zawsze dokumentuję za pomocą fio‑percentyle opóźnienia, zanim trafią do środowiska produkcyjnego.

Limity, projekty i izolacja

W środowiskach wielodostępnych stawiam na Limity projektowe, aby ładunki i zajmowana przestrzeń były wyraźnie oddzielone od siebie. Montuję za pomocą prjquota oraz zarządzam granicami za pośrednictwem xfs_quota aksamit /etc/projects oraz /etc/projid. W ten sposób można na przykład nałożyć ścisłe ograniczenia na katalogi kompilacji, instancje baz danych lub katalogi klientów, nie ograniczając przy tym równoległości AG.

W przypadku drzew katalogów, w których dominuje operacja ingest i które sekwencyjnie zapisują wiele dużych plików, można strumienie plików‑Allocator może okazać się przydatny. Zapewnia on większą spójność plików w katalogu i ogranicza fragmentację. Włączam go celowo za pomocą opcji montowania w przypadku woluminów, które są wyraźnie przeznaczone do strumieniowania, i mierzę wpływ tej opcji na przepustowość oraz obciążenie procesora.

Wzrost, migawki i cykl życia

XFS może rozwijać się w sieci, ale nie zmniejszać się. Dlatego planuję pojemność i układ serwerów tak, aby przyszłe rozbudowy za pomocą LVM/VMDK były możliwe bez problemów. Z xfs_growfs /mount rozszerzam system plików w górę, a struktura AG rośnie wraz z nim. Parametry takie jak sunit oraz swidth są ustalone – dlatego osoba zmieniająca geometrię macierzy RAID powinna uwzględnić w planach ponowne sformatowanie i przywrócenie danych.

Dla spójności Migawki W połączeniu z LVM lub backendami pamięci masowej na chwilę zamrażam system plików: xfs_freeze -f /mount, utworzyć migawkę, xfs_freeze -u /mount. Minimalizuje to odtwarzanie logów i gwarantuje bezbłędne przywracanie danych. Jeśli chodzi o stan systemu w trakcie działania, planuję regularne xfs_scrub (jeśli jest dostępna) i przytrzymaj xfs_repair dostępne jako narzędzie offline. Dane SMART, nvme smart-log oraz iostat -x znajdują się na mojej liście obserwowanych, aby wcześnie wykryć pogorszenie stanu.

Metodologia testowania i wiarygodne wartości odniesienia

Zanim zastąpię ustawienia domyślne, przeprowadzam pomiary, które dają powtarzalne wyniki. Zaczynam od jasno określonych fio‑Profile, które osobno uwzględniają IOPS, przepustowość i opóźnienie oraz obejmują fazy rozgrzewania:

[global]
ioengine=io_uring
direct=1
runtime=60
time_based=1
group_reporting=1
randrepeat=0

[randread-4k]
filename=/data/testfile
rw=randread
bs=4k
iodepth=64
numjobs=8

[randwrite-4k]
filename=/data/testfile
rw=randwrite
bs=4k
iodepth=64
numjobs=8

[seqread-1m]
filename=/data/testfile
rw=read
bs=1m
iodepth=32
numjobs=4

[seqwrite-1m]
filename=/data/testfile
rw=write
bs=1m
iodepth=32
numjobs=4

W zależności od celu dostosowuję się numjobs do rdzeni procesora oraz iodepth do żądanej głębokości kolejki. Ważne jest zachowanie spójnych warunków brzegowych (ten sam poziom wypełnienia, identyczne opcje montowania, prawidłowo przycięty wolumin). Wartości odstające filtruję, porównując średnie i 99. percentyl z kilku przebiegów. W ten sposób podejmuję uzasadnione decyzje między brak oraz mq-deadline, między mniejszym a większym allocsize lub w kwestii tego, czy zewnętrzny dziennik rzeczywiście jest pomocny.

Precyzyjne dostosowanie parametrów allocsize, Reflink i innych.

allocsize jest przydatnym narzędziem, ale nie jest panaceum. W przypadku czysto losowych drobnych operacji zapisu zbyt duże bloki alokacji powodują niepotrzebne obciążenie związane z zapisem. Dlatego w zależności od obciążenia wybieram konserwatywne wartości i sprawdzam fragmentację oraz opóźnienia. Gdy Reflink jest włączony, unikam ciągłych drobnych aktualizacji w tych samych obszarach plików, ponieważ CoW wiąże się z dodatkową obsługą metadanych. Jeśli potrzebuję szybkich klonów, utrzymuję duże bufory dziennika i dbam o dużą ilość wolnej, spójnej przestrzeni w kilku grupach roboczych.

Bezpieczne wartości domyślne: bariery, odrzucanie i spójność

Bariery w pisaniu (Bariery zapisu) oraz FUA są domyślnie aktywne w nowoczesnych stosach – nie zamierzam tego zmieniać, aby uniknąć ryzyka utraty danych. nobarrier Nie wchodzi to dla mnie w grę, nawet jeśli wyniki poszczególnych testów wydajnościowych na krótką metę się poprawią. odrzucić na Mount nie działa, ogólnosystemowy fstrim‑Timer skutecznie wykonuje operację TRIM w fazach bezczynności. To połączenie zapewnia mi niezawodnie niskie opóźnienia przy wysokiej stabilności wydajności dysku SSD.

Krótkie podsumowanie

System plików XFS zapewnia skalowalność horyzontalną dzięki grupom alokacji, wykorzystując w ten sposób naturalną równoległość NVMe w praktyce. Liczbę procesów, rozmiary bloków, opcje montowania i harmonogram nie ustalam na podstawie przeczucia, lecz na podstawie profilu obciążenia i danych pomiarowych. W przypadku niewielkich operacji zapisu losowego liczy się precyzyjne wyrównanie i oszczędny harmonogram, natomiast w przypadku dużych strumieni raczej hojne allocsize oraz readahead. Typowe problemy, takie jak niezrównoważone grupy robocze czy synchroniczne odrzucanie danych, rozwiązuję poprzez ponowny podział i okresowe fstrim. Kto systematycznie reguluje te parametry, utrzymuje niskie opóźnienia, zwiększa liczbę operacji IOPS i zapewnia trwałą Wydajność.