Edwarda Szyszkina nowe możliwości opracowane w ramach projektu Reiser5. Reiser5 znacznie przeprojektowana wersja systemu plików ReiserFS, w której obsługa równoległych skalowalnych woluminów logicznych jest zaimplementowana na poziomie systemu plików, a nie na poziomie urządzenia blokowego, co pozwala na efektywną dystrybucję danych w wolumenie logicznym.
Wśród wprowadzonych ostatnio innowacji znalazło się m.in
możliwość dodania przez użytkownika niewielkiej, wysokiej wydajności
urządzenie blokujące (np. NVRAM) o nazwie do
stosunkowo duży wolumin logiczny złożony z powolnego
napędy budżetowe. To sprawi wrażenie, że wszystko
objętość składa się z tych samych drogich, wysokiej wydajności
urządzeń, takich jak „dysk proxy”.
Zaimplementowana metoda opierała się na prostej obserwacji, że w praktyce dysk nie jest zapisywany w sposób ciągły, a krzywa obciążenia wejść/wyjść ma kształt pików. W przerwach pomiędzy takimi „szczytami” zawsze istnieje możliwość zresetowania danych z dysku proxy, przepisując wszystkie dane (lub tylko część) w tle do głównej, „wolnej” pamięci. Dzięki temu dysk proxy jest zawsze gotowy na przyjęcie nowej porcji danych.
Technika ta (znana jako bufory wybuchowe) pierwotnie powstała w
obszarach obliczeń o wysokiej wydajności (HPC). Ale okazało się, że jest również zapotrzebowanie na zwykłe aplikacje, zwłaszcza te, które stawiają zwiększone wymagania w zakresie integralności danych (zwykle różnego rodzaju bazy danych). Takie aplikacje dokonują wszelkich zmian w dowolnym pliku w sposób atomowy, a mianowicie:
Zwalnia bloki zajmowane przez stare dane.
Wszystkie te kroki, w takim czy innym stopniu, powodują znaczące
spadek wydajności w dowolnym systemie plików. Sytuacja
poprawia się, jeśli nowy plik jest najpierw zapisywany w przydzielonym pliku
urządzenie o wysokiej wydajności, co jest dokładnie tym, co dzieje się w
system plików z obsługą buforów Burst.
W Reiser5 planowane jest opcjonalnie wysyłanie nie tylko
nowe bloki logiczne pliku, ale także wszystkie brudne strony w ogóle. Ponadto,
nie tylko strony z danymi, ale także z metadanymi, które
są zapisane w krokach (2) i (3).
Obsługa dysków proxy odbywa się w kontekście regularnej pracy z
woluminy logiczne Reiser5, na początku roku. To jest,
zagregowany system „dysk proxy - pamięć główna” jest normalny
wolumin logiczny, z tą tylko różnicą, że dysk proxy ma pierwszeństwo
wśród innych składników woluminu w zasadach alokacji adresów dyskowych.
Dodaniu dysku proxy do woluminu logicznego nie towarzyszy żaden komunikat
rebalansowanie danych, a ich usunięcie odbywa się dokładnie w taki sam sposób jak
wyjmowanie zwykłego dysku. Wszystkie operacje na dysku proxy są niepodzielne.
Obsługa błędów i wdrażanie systemu (w tym po awarii systemu) odbywa się dokładnie w taki sam sposób, jak gdyby dysk proxy był zwykłym komponentem
objętość logiczna.
Po dodaniu dysku proxy całkowita pojemność woluminu logicznego
zwiększa się o pojemność tego dysku. Monitorowanie wolnej przestrzeni
dysk proxy odbywa się w taki sam sposób, jak w przypadku innych składników wolumenu, tj. za pomocą narzędzia Volume.reiser4(8).
Dysk proxy należy okresowo czyścić, tj. zresetuj dane z
go do głównego magazynu. Po osiągnięciu stabilności beta Reiser5
czyszczenie planowane jest na automatyczne (będzie nim zarządzał
specjalny wątek jądra). Na tym etapie odpowiedzialność za sprzątanie
spoczywa na użytkowniku. Resetowanie danych z dysku proxy na główny
Storage tworzy się po prostu wywołując narzędzie Volume.reiser4 z opcją
"-B". Jako argument musisz określić punkt podłączenia logicznego
wolumeny Oczywiście trzeba pamiętać o okresowym przeprowadzaniu czyszczenia. Dla
Aby to zrobić, możesz napisać prosty skrypt powłoki.
Jeśli na dysku proxy nie ma wolnego miejsca, wszystkie dane
są automatycznie zapisywane w pamięci głównej. Jednocześnie domyślnie
ogólna wydajność FS jest zmniejszona (z powodu ciągłych wywołań
procedury zatwierdzania wszystkich istniejących transakcji). Opcjonalnie możesz ustawić
trybie bez utraty wydajności. Jednak w tym przypadku dysk
Przestrzeń urządzenia proxy będzie wykorzystywana mniej efektywnie.
Wygodnie jest używać podsekcji metadanych (kostki) jako dysku proxy, pod warunkiem, że jest ona utworzona na urządzeniu blokowym o wystarczająco dużej wydajności.
Źródło: opennet.ru