Opublikowano drugi wywiad z Eduardem Shishkinem, twórcą systemu plików Reiser4.
Na początek przypomnij czytelnikom, gdzie i dla kogo pracujesz.
Pracuję jako główny architekt pamięci masowej w Huawei Technologies, niemieckim centrum badawczym. W dziale wirtualizacji zajmuję się różnymi aspektami przechowywania danych. Moja działalność nie jest związana z konkretnym systemem operacyjnym.
Czy obecnie angażujesz się w główną gałąź jądra?
Bardzo rzadko i tylko wtedy, gdy wymaga tego mój pracodawca. Ostatni raz około trzy lata temu wysłałem łatki zwiększające przepustowość pamięci współdzielonej na hostach przy użyciu protokołu 9p (inna nazwa tej firmy to VirtFS). Trzeba tu poczynić jedną ważną uwagę: choć z Linuksem pracuję od dawna, nigdy nie byłem jego fanem, czyli „oddycham równomiernie”, jak ze wszystkim innym. Zwłaszcza, jeśli zauważę jakąś wadę, to mogę ją wskazać najwyżej raz. A żebyś potem mógł kogoś śledzić i przekonywać - tak się nie stanie.
Pamiętam, że ostatnim razem, dziesięć lat temu, byłeś dość krytyczny wobec stylu programowania jądra. Czy z Twojego (a może korporacyjnego) punktu widzenia coś się zmieniło, czy społeczność stała się bardziej responsywna, czy nie? Jeśli nie, kto według Ciebie jest winny?
Nigdy nie widziałem żadnych zmian na lepsze. Głównym problemem społeczności jest zastępowanie nauki technologiami politycznymi, relacjami osobistymi, opinią większości, populizmem, radami „głosów wewnętrznych”, zgniłymi kompromisami, wszystkim oprócz nauki. Informatyka, jakkolwiek by się nie powiedzieć, jest przede wszystkim nauką ścisłą. A jeśli ktoś zacznie głosić swoją własną wartość dla 2x2, inną niż 4, pod flagą „Linux Way” lub pod jakąś inną flagą, jest mało prawdopodobne, że przyniesie to coś innego niż szkodę.
Wszystkie problemy wynikają przede wszystkim z niekompetencji i braku wykształcenia osób podejmujących decyzje. Jeśli menedżer jest niekompetentny, nie jest w stanie podjąć obiektywnej, właściwej decyzji. Jeśli jest też niekulturalny, nie jest w stanie znaleźć kompetentnego specjalisty, który udzieli mu właściwej rady. Z dużym prawdopodobieństwem wybór padnie na oszusta, który mówi „rzeczy pozornie słuszne”. Skorumpowane środowisko zawsze rozwija się wokół niekompetentnych, samotnych przywódców. Co więcej, historia nie zna pod tym względem wyjątków, a wspólnota jest tego najwyraźniejszym potwierdzeniem.
Jak oceniasz postęp w rozwoju Btrfs? Czy ten FS pozbył się chorób dziecięcych? Jak ustawić go dla siebie – jako FS „do domu”, czy też do użytku korporacyjnego?
Nie pozbyłem się tego. Wszystko, o czym wspomniałem 11 lat temu, jest nadal aktualne. Jednym z problemów związanych z Btrfs, który sprawia, że nie nadaje się on do poważnych potrzeb, jest problem wolnej przestrzeni. Już nawet nie mówię o tym, że użytkownik proszony jest o pobiegnięcie do sklepu po nowy dysk w sytuacji, gdy jakikolwiek inny FS pokazywałby dużo wolnego miejsca na partycji. Niemożność wykonania operacji na woluminie logicznym z powodu braku wolnego miejsca również nie jest najgorsza. Najgorsze jest to, że nieuprzywilejowany użytkownik prawie zawsze może ominąć dowolne przydziały dysku, pozbawić wszystkich wolnego miejsca w dość krótkim czasie.
Wygląda to tak (testowane dla jądra Linuksa 5.12). Na świeżo zainstalowanym systemie uruchamiany jest skrypt, który w pętli tworzy w katalogu domowym pliki o określonych nazwach, zapisuje do nich dane w określonych przesunięciach, a następnie usuwa te pliki. Po minucie działania tego skryptu nie dzieje się nic niezwykłego. Po pięciu minutach część zajmowanego miejsca na partycji nieznacznie wzrasta. Po dwóch, trzech godzinach osiąga 50% (przy wartości początkowej 15%). A po pięciu lub sześciu godzinach pracy skrypt ulega awarii z błędem „na partycji nie ma wolnego miejsca”. Po tym nie będziesz już mógł zapisać na swojej partycji nawet pliku 4K.
Występuje interesująca sytuacja: ostatecznie nie zapisałeś nic na partycję, a całe wolne miejsce (około 85%) gdzieś zniknęło. Analiza sekcji podlegającej takiemu atakowi ujawni wiele węzłów drzewa zawierających tylko jeden element (obiekt wyposażony w klucz) o rozmiarze kilku bajtów. Oznacza to, że zawartość, która wcześniej zajmowała 15% miejsca na dysku, okazała się równomiernie „rozmazana” na całej partycji, tak że nie ma gdzie zapisać nowego pliku, ponieważ jego klucz jest większy niż wszystkie istniejące, a wolny skończyły się bloki na partycji.
Co więcej, wszystko to dzieje się już w podstawowej konfiguracji Btrfs (bez żadnych migawek, podwoluminów itp.) i nie ma znaczenia, w jaki sposób zdecydujesz się przechowywać treści plików w tym systemie plików (jako „fragmenty” w drzewie lub jako zakresy niesformatowanych bloków) - efekt końcowy będzie taki sam.
Nie będziesz w stanie narazić innych systemów plików nadrzędnych na taki atak (bez względu na to, co ci powiedzą). Przyczynę problemu wyjaśniłem dawno temu: jest to całkowite wypaczenie koncepcji drzewa B w Btrfs, które umożliwia jego spontaniczną lub celową degenerację. W szczególności pod pewnymi obciążeniami system plików będzie się stale „rozpadał” podczas działania samodzielnie, bez pomocy z zewnątrz. Oczywiste jest, że wszelkiego rodzaju „naciśnięcie” procesów w tle uratuje dzień tylko na poszczególnych komputerach stacjonarnych.
Na serwerach zbiorowych atakujący zawsze będzie w stanie go „wyprzedzić”. Administrator systemu nie będzie nawet w stanie ustalić, kto dokładnie go znęcał. Najszybszym sposobem rozwiązania tego problemu w Btrfs jest przywrócenie struktury zwykłego drzewa B, tj. przeprojektowanie formatu dysku i przepisanie znacznych części kodu Btrfs. Zajmie to 8-10 lat, łącznie z debugowaniem, pod warunkiem, że programiści ściśle przestrzegali oryginalnych artykułów na temat odpowiednich algorytmów i struktur danych i nie grali w grę „zepsuty telefon”, jak jest to zwyczajowo (i do czego zachęca się) w „Linuksowym wydaniu” sposób".
Tutaj również musimy dodać czas potrzebny programistom na zrozumienie tego wszystkiego. Tutaj jest już trudniej. W każdym razie 10 lat nie wystarczyło, żeby zrozumieli. Cóż, do tego czasu nie można liczyć na cud. Nie stanie się to w formie opcji montażu, „o której ty i ja nie wiedzieliśmy” ani w formie łatki, której przygotowanie jest „tylko sprawą biznesową”. Dla każdej takiej pochopnej „naprawy” przedstawię nowy scenariusz degeneracji. Drzewa B to jeden z moich ulubionych tematów i muszę powiedzieć, że te struktury nie tolerują swobód same w sobie!
Jak ustawić Btrfs dla siebie? Jako coś, czego absolutnie nie można nazwać systemem plików, a co dopiero używać. Ponieważ z definicji FS jest podsystemem systemu operacyjnego odpowiedzialnym za efektywne zarządzanie zasobem „przestrzeni dyskowej”, czego nie widzimy w przypadku Btrfs. No cóż, wyobraź sobie, że przyszedłeś do sklepu kupić zegarek, żeby nie spóźnić się do pracy, a zamiast zegarka sprzedali Ci grill elektryczny z timerem na maksymalnie 30 minut. Zatem sytuacja z Btrfs jest jeszcze gorsza.
Przeglądając listy mailingowe często spotykam się ze stwierdzeniem, że efektywne zarządzanie przestrzenią dyskową nie ma już sensu ze względu na taniość dysków. To kompletny nonsens. Bez skutecznego menedżera miejsca na dysku system operacyjny stanie się podatny na ataki i bezużyteczny. Niezależnie od pojemności dysków w Twojej maszynie.
Chciałbym prosić o komentarz w sprawie zaprzestania wsparcia Btrfs w RHEL.
Nie ma tu nic specjalnego do komentowania, wszystko jest bardzo jasne. Mieli to także jako „zapowiedź technologii”. Więc nie przeglądałem tego bardzo „podglądu”. Nie pozwól, aby ta etykieta wisiała wiecznie! Nie mogą jednak wypuścić wadliwego produktu na podstawie projektu przy pełnym wsparciu. RHEL to przedsiębiorstwo, czyli określone relacje towarowo-pieniężne. Red Hat nie może znęcać się nad użytkownikami tak, jak robią to na liście mailingowej Btrfs. Wyobraź sobie sytuację: klient, który zapłacił za dysk swoje ciężko zarobione pieniądze, a Ty za wsparcie, chce wiedzieć, gdzie podziało się jego miejsce na dysku, kiedy nic nie zapisał. Co mu na to odpowiesz?
Dalej. Klientami Red Hata są znane duże banki i giełdy. Wyobraź sobie, co by się stało, gdyby padły ofiarą ataków DoS opartych na wspomnianej luce w Btrfs. Jak myślisz, kto jest za to odpowiedzialny? Tym, którzy będą wskazywać palcem na wiersz licencji GPL, gdzie jest napisane, że autor za nic nie odpowiada, od razu powiem: „schowajcie to!”. Red Hat odpowie i to w taki sposób, że to nie będzie wystarczające! Wiem jednak, że Red Hat nie boryka się z tego typu problemami, biorąc pod uwagę ich szczególnie silny zespół inżynierów ds. kontroli jakości, z którymi miałem okazję blisko współpracować w swoim czasie.
Dlaczego niektóre firmy nadal wspierają Btrfs w swoich produktach dla przedsiębiorstw?
Należy pamiętać, że przedrostek „przedsiębiorstwo” w nazwie produktu niewiele znaczy. Przedsięwzięcie jest miarą odpowiedzialności zakorzenioną w relacji kontraktowej z klientem. Znam tylko jedno przedsiębiorstwo oparte na GNU/Linux – RHEL. Wszystko inne, z mojego punktu widzenia, jest przedstawiane jedynie jako przedsiębiorstwo, ale nim nie jest. I wreszcie, jeśli jest na coś popyt, to zawsze będzie podaż (w naszym przypadku jest to wspomniane „wsparcie”). Jest popyt na absolutnie wszystko, m.in. i nieużyteczne oprogramowanie. To, jak powstaje taki popyt i kto go napędza, to już inny temat.
Nie wyciągałbym więc żadnych pochopnych wniosków po tym, jak pojawiły się plotki o wdrożeniu przez Facebooka Btrfs na swoich serwerach. Co więcej, z powyższych powodów zalecałbym dokładne utrzymywanie w tajemnicy adresów tych serwerów.
Dlaczego ostatnio tak wiele wysiłku włożono w oczyszczenie kodu XFS? W końcu początkowo jest to system plików innej firmy, a ext4 jest stabilny przez długi czas i ma ciągłość z poprzednich, równie stabilnych wersji. Jakie zainteresowanie Red Hat ma XFS? Czy ma sens aktywne rozwijanie dwóch systemów plików o podobnym przeznaczeniu - ext4 i XFS?
Nie pamiętam, co było tego motywacją. Całkiem możliwe, że inicjatywa wyszła od klientów Red Hata. Pamiętam, że prowadzono tego typu badania: na niektórych systemach plików pochodzących z wyższego źródła, na high-endowych dyskach nowej generacji tworzono gigantyczną liczbę obiektów. Według wyników XFS zachowywał się lepiej niż ext4. Zaczęto więc go promować jako najbardziej obiecujący. W każdym razie nie szukałbym tu niczego sensacyjnego.
Dla mnie to tak, jakby zastąpili szydło mydłem. Nie ma sensu rozwijać ext4 i XFS. Zarówno równolegle jak i dowolne z nich do wyboru. Nic dobrego z tego nie wyniknie. Choć w przyrodzie często zdarzają się sytuacje, gdy potencjał do wzrostu jest duży, ale nie ma miejsca na rozwój. W tym przypadku pojawiają się różne dziwnie brzydkie nowe narośla, na które wszyscy wskazują palcem („Och, spójrz, czego nie zobaczysz w tym życiu!”).
Czy uważasz, że kwestia naruszenia warstw została rozwiązana (w negatywnym sensie) wraz z pojawieniem się funkcji szyfrowania w ext4, F2FS (nie wspominając o RAID w Btrfs)?
Generalnie wprowadzenie jakichkolwiek poziomów i podjęcie decyzji o ich nienaruszaniu jest zazwyczaj kwestią polityki i nie podejmuję się tutaj komentowania czegokolwiek. Obiektywne aspekty naruszenia warstwy nikogo nie interesują, ale niektóre z nich możemy rozważyć na przykładzie naruszenia „od góry”, a mianowicie implementacji w FS funkcjonalności, która już istnieje w warstwie blokowej. Takie „naruszenie” jest uzasadnione jedynie nielicznymi wyjątkami. W każdym takim przypadku musisz najpierw udowodnić dwie rzeczy: że jest to naprawdę potrzebne i że nie zaszkodzi to konstrukcji systemu.
Na przykład tworzenie kopii lustrzanych, które tradycyjnie było czynnością wykonywaną w warstwie blokowej, warto wdrożyć na poziomie systemu plików. Z różnych powodów. Na przykład na dyskach dochodzi do „cichego” uszkodzenia danych (zgnilizny bitów). Dzieje się tak wtedy, gdy urządzenie działa prawidłowo, ale dane blokowe ulegają nieoczekiwanemu uszkodzeniu pod wpływem twardego kwantu gamma emitowanego przez odległy kwazar itp. Najgorsze jest, jeśli ten blok okaże się blokiem systemu FS (superblok, blok mapy bitowej, węzeł drzewa pamięci itp.), ponieważ z pewnością doprowadzi to do paniki jądra.
Należy pamiętać, że lustra oferowane przez warstwę blokową (tzw. RAID 1) nie uchronią Cię od tego problemu. No właśnie: ktoś powinien sprawdzić sumy kontrolne i przeczytać replikę w przypadku awarii? Ponadto sensowne jest odzwierciedlanie nie tylko wszystkiego, ale tylko metadanych. Niektóre ważne dane (na przykład pliki wykonywalne krytycznych aplikacji) mogą być przechowywane jako metadane. W tym przypadku otrzymują takie same gwarancje bezpieczeństwa. Ochronę pozostałych danych warto powierzyć innym podsystemom (być może nawet aplikacjom użytkownika) – zapewniliśmy ku temu wszystkie niezbędne warunki.
Takie „ekonomiczne” kopie lustrzane mają prawo istnieć i można je skutecznie zorganizować jedynie na poziomie systemu plików. W przeciwnym razie naruszeniem warstw jest zaśmiecanie podsystemu zduplikowanym kodem w imię mikroskopijnych korzyści. Uderzającym tego przykładem jest implementacja RAID-5 przy użyciu FS. Takie rozwiązania (własny RAID/LVM w systemie plików) zabijają ten ostatni pod względem architektonicznym. Należy również zauważyć, że naruszenie warstw jest „upubliczniane” przez różnego rodzaju oszustów marketingowych. W przypadku braku pomysłów do podsystemów dodawana jest funkcjonalność, która od dawna jest wdrażana na sąsiednich poziomach, jest to przedstawiane jako nowa niezwykle przydatna funkcja i aktywnie promowana.
Reiser4 został oskarżony o naruszenie poziomów „od dołu”. Bazując na tym, że system plików nie jest monolityczny, jak wszystkie inne, ale modułowy, przyjęto bezpodstawne założenie, że robi to, co powinien robić wyższy poziom (VFS).
Czy można mówić o śmierci ReiserFS v3.6 i np. JFS? Ostatnio w rdzeniu nie poświęcano im prawie żadnej uwagi. Czy są przestarzałe?
W tym miejscu musimy zdefiniować, co oznacza śmierć oprogramowania. Z jednej strony są z powodzeniem wykorzystywane (w końcu do tego zostały stworzone), a co za tym idzie – żyją. Z drugiej strony nie mogę się wypowiadać za JFS (niewiele się na tym znam), ale ReiserFS (v3) bardzo trudno dostosować do nowych trendów (przetestowany w praktyce). Oznacza to, że w przyszłości programiści będą zwracać uwagę nie na to, ale na te, które łatwiej zaadaptować. Od tej strony okazuje się, że niestety jest martwy architektonicznie. W żadnym wypadku nie manipulowałbym koncepcją „moralnie przestarzałego”. Dobrze sprawdza się na przykład w przypadku garderoby, ale nie w przypadku oprogramowania. W czymś istnieje koncepcja niższości i wyższości. Mogę z całą pewnością powiedzieć, że ReserFS v3 jest teraz gorszy od Reiser4 pod każdym względem, ale w niektórych typach obciążeń jest lepszy od wszystkich innych wcześniejszych systemów FS.
Czy wiesz o rozwoju FS Tux3 i HAMMER/HAMMER2 (FS dla DragonFly BSD)?
Tak wiemy. W Tux3 kiedyś interesowałem się technologią ich snapshotów (tzw. „wskaźniki wersji”), ale w Reiser4 najprawdopodobniej pójdziemy inną drogą. Długo zastanawiałem się nad obsługą migawek i jeszcze nie zdecydowałem, jak je zaimplementować dla prostych wolumenów Reiser4. Faktem jest, że nowomodna technika „leniwego” licznika referencji zaproponowana przez Ohada Rodeha działa tylko w przypadku drzew B. Nie mamy ich. Dla tych struktur danych, które są używane w Reiesr4, nie zdefiniowano „leniwych” liczników - aby je wprowadzić, konieczne jest rozwiązanie pewnych problemów algorytmicznych, których nikt jeszcze nie podjął.
Zdaniem HAMMERA: Czytałem artykuł twórcy. Nie zainteresowany. Znowu drzewa B. Ta struktura danych jest beznadziejnie przestarzała. Porzuciliśmy to w zeszłym stuleciu.
Jak oceniasz rosnące zapotrzebowanie na FS klastrów sieciowych, takie jak CephFS/GlusterFS/itp.? Czy to żądanie oznacza zmianę priorytetów deweloperów w kierunku sieciowego FS i niewystarczającą uwagę na lokalnym FS?
Tak, taka zmiana priorytetów nastąpiła. Rozwój lokalnych systemów plików uległ stagnacji. Niestety, zrobienie czegoś znaczącego dla woluminów lokalnych jest teraz dość trudne i nie każdy może to zrobić. Nikt nie chce inwestować w swój rozwój. To mniej więcej to samo, co poprosić organizację komercyjną o przeznaczenie pieniędzy na badania matematyczne – bez entuzjazmu zapytają cię, jak możesz zarobić na nowym twierdzeniu. Teraz lokalny FS jest czymś, co w magiczny sposób pojawia się „od razu po wyjęciu z pudełka” i „powinno zawsze działać”, a jeśli nie działa, powoduje nieadresowane narzekanie w stylu: „Tak, o czym oni myślą!”
Stąd brak zainteresowania lokalnymi FS, choć pracy w tym obszarze jest jeszcze sporo. I tak, wszyscy zwrócili się w stronę rozproszonej pamięci masowej, która jest zbudowana w oparciu o już istniejące lokalne systemy plików. To teraz bardzo modne. Określenie „Big Data” wywołuje u wielu przypływ adrenaliny, kojarząc je z konferencjami, warsztatami, dużymi zarobkami itp.
Jak rozsądne jest w zasadzie wdrożenie sieciowego systemu plików w przestrzeni jądra, a nie w przestrzeni użytkownika?
Bardzo rozsądne podejście, które nie zostało jeszcze nigdzie wdrożone. Ogólnie rzecz biorąc, kwestia tego, w jakim obszarze powinien zostać zaimplementowany sieciowy system plików, jest „mieczem obosiecznym”. Cóż, spójrzmy na przykład. Klient zapisał dane na zdalnym komputerze. Wpadły do jej pamięci podręcznej stron w postaci brudnych stron. To jest zadanie dla sieciowego systemu plików „cienkiej bramy” w przestrzeni jądra. Wtedy system operacyjny prędzej czy później poprosi Cię o zapisanie tych stron na dysku w celu ich zwolnienia. Następnie do gry wchodzi moduł sieciowy FS przekazujący IO (wysyłający). Określa, do którego serwera (węzła serwera) trafią te strony.
Następnie stery przejmuje stos sieciowy (i jak wiemy jest on zaimplementowany w przestrzeni jądra). Następnie węzeł serwera odbiera ten pakiet z danymi lub metadanymi i instruuje moduł pamięci masowej zaplecza (tj. lokalny system plików działający w przestrzeni jądra), aby zapisał wszystkie te dane. Dlatego ograniczyliśmy pytanie do tego, gdzie powinny działać moduły „wysyłanie” i „odbieranie”. Jeśli którykolwiek z tych modułów zostanie uruchomiony w przestrzeni użytkownika, nieuchronnie doprowadzi to do przełączenia kontekstu (ze względu na konieczność korzystania z usług jądra). Liczba takich przełączników zależy od szczegółów implementacji.
Jeśli jest wiele takich przełączników, przepustowość pamięci (wydajność we/wy) spadnie. Jeśli pamięć zaplecza składa się z wolnych dysków, nie zauważysz znaczącego spadku. Ale jeśli masz szybkie dyski (SSD, NVRAM itp.), wówczas przełączanie kontekstu staje się już „wąskim gardłem”, a oszczędzając na przełączaniu kontekstu, można znacznie zwiększyć wydajność. Standardowym sposobem na zaoszczędzenie pieniędzy jest przeniesienie modułów do przestrzeni jądra. Na przykład odkryliśmy, że przeniesienie serwera 9p z QEMU do jądra na komputerze hosta prowadzi do trzykrotnego wzrostu wydajności VirtFS.
To oczywiście nie jest sieciowy FS, ale w pełni oddaje istotę rzeczy. Wadą tej optymalizacji są problemy z przenośnością. Dla niektórych to drugie może być krytyczne. Na przykład GlusterFS nie ma w ogóle żadnych modułów w jądrze. Dzięki temu działa teraz na wielu platformach, w tym na NetBSD.
Jakie koncepcje lokalne FS mogą zapożyczyć od sieciowych i odwrotnie?
Obecnie sieciowe FS z reguły mają dodatki w stosunku do lokalnych FS, więc nie do końca rozumiem, jak można pożyczyć coś od tych ostatnich. No cóż, rozważmy firmę składającą się z 4 pracowników, w której każdy robi swoje: jeden rozprowadza, drugi wysyła, trzeci odbiera, czwarty przechowuje. A pytanie, co firma może pożyczyć od przechowującego to pracownika, brzmi jakoś niepoprawnie (co mogła od niego pożyczyć, już dawno miała).
Jednak lokalne systemy zabezpieczeń mogą się wiele nauczyć od sieciowych. Po pierwsze, należy się od nich nauczyć, jak agregować woluminy logiczne na wysokim poziomie. Teraz tzw „zaawansowane” lokalne systemy plików agregują woluminy logiczne wyłącznie przy użyciu technologii „urządzeń wirtualnych” zapożyczonej od LVM (to samo naruszenie infekcyjnego nakładania warstw, które zostało po raz pierwszy zaimplementowane w ZFS). Innymi słowy, tłumaczenie adresów wirtualnych (numerów bloków) na adresy rzeczywiste i odwrotnie odbywa się na niskim poziomie (tj. po wysłaniu przez system plików żądania wejścia/wyjścia).
Należy pamiętać, że dodawanie i usuwanie urządzeń do woluminów logicznych (nie kopii lustrzanych) rozmieszczonych na warstwie blokowej prowadzi do problemów, o których dostawcy tego typu „funkcji” skromnie milczą. Mówię o fragmentacji na rzeczywistych urządzeniach, która potrafi osiągać monstrualne wartości, natomiast na urządzeniu wirtualnym wszystko jest w porządku. Jednak niewiele osób interesuje się urządzeniami wirtualnymi: wszyscy interesują się tym, co dzieje się na Twoich prawdziwych urządzeniach. Ale FS podobny do ZFS (a także dowolny FS w połączeniu z LVM) działa tylko z urządzeniami dysków wirtualnych (przydzielaj adresy dysków wirtualnych spośród wolnych, defragmentuj te urządzenia wirtualne itp.). I nie mają pojęcia, co dzieje się na prawdziwych urządzeniach!
Teraz wyobraź sobie, że masz zerową fragmentację na urządzeniu wirtualnym (to znaczy, że mieszkasz tam tylko jeden gigantyczny obszar), dodajesz dysk do woluminu logicznego, a następnie usuwasz kolejny losowy dysk z woluminu logicznego, a następnie przywracasz równowagę. I tak wiele razy. Nietrudno sobie wyobrazić, że na urządzeniu wirtualnym nadal będziesz żył w tym samym stopniu, ale na prawdziwych urządzeniach nie zobaczysz nic dobrego.
Najgorsze jest to, że nie jesteś w stanie nawet naprawić tej sytuacji! Jedyne, co możesz tutaj zrobić, to poprosić system plików o defragmentację urządzenia wirtualnego. Ale powie Ci, że tam wszystko jest świetnie – jest tylko jeden stopień, fragmentacja jest zerowa i nie może być lepiej! Zatem woluminy logiczne ułożone na poziomie bloku nie są przeznaczone do wielokrotnego dodawania/usuwania urządzeń. W dobrym tego słowa znaczeniu wystarczy tylko raz złożyć wolumin logiczny na poziomie bloku, przekazać go systemowi plików i nie robić z nim nic więcej.
Dodatkowo połączenie niezależnych podsystemów FS+LVM nie pozwala na uwzględnienie odmiennego charakteru dysków, z których agregowane są woluminy logiczne. Załóżmy, że zmontowałeś wolumin logiczny z dysków twardych i urządzeń półprzewodnikowych. Ale wtedy ten pierwszy będzie wymagał defragmentacji, a drugi nie. W przypadku tego drugiego musisz wystawiać żądania odrzucenia, ale w przypadku pierwszego nie itp. Jednak w tym zestawieniu dość trudno wykazać taką selektywność.
Należy pamiętać, że po utworzeniu własnego LVM w systemie plików sytuacja nie ulega znacznej poprawie. Co więcej, robiąc to, w rzeczywistości kładziesz kres perspektywie poprawy tego w przyszłości. To jest bardzo złe. Różne typy dysków mogą znajdować się na tej samej maszynie. A jeśli system plików ich nie rozróżnia, to kto to zrobi?
Kolejnym problemem jest oczekiwanie na tzw. Systemy plików „Write-Anywhere” (dotyczy to również Reiser4, jeśli podczas montowania określiłeś odpowiedni model transakcyjny). Takie systemy plików muszą zapewniać narzędzia do defragmentacji o niespotykanej dotąd mocy. A menedżer głośności niskiego poziomu tutaj nie pomaga, a jedynie przeszkadza. Faktem jest, że przy takim menedżerze Twój FS będzie przechowywać mapę wolnych bloków tylko jednego urządzenia - wirtualnego. W związku z tym można defragmentować jedynie urządzenie wirtualne. Oznacza to, że Twój defragmentator będzie działał przez długi, długi czas na ogromnej pojedynczej przestrzeni adresów wirtualnych.
A jeśli wielu użytkowników wykonuje losowe nadpisywanie, wówczas użyteczny efekt takiego defragmentatora zostanie zredukowany do zera. Twój system nieuchronnie zacznie zwalniać, a Ty będziesz musiał jedynie złożyć ręce przed rozczarowującą diagnozą „zepsuty projekt”. Kilka defragmentatorów działających w tej samej przestrzeni adresowej będzie tylko kolidować ze sobą. Zupełnie inna sprawa, jeśli utrzymujesz własną mapę wolnych bloków dla każdego realnego urządzenia. To skutecznie zrównolegli proces defragmentacji.
Można to jednak zrobić tylko wtedy, gdy masz menedżera woluminów logicznych wysokiego poziomu. Lokalne systemy plików z takimi menedżerami wcześniej nie istniały (przynajmniej ja o nich nie wiem). Tylko sieciowe systemy plików (na przykład GlusterFS) miały takich menedżerów. Innym bardzo ważnym przykładem jest narzędzie do sprawdzania integralności woluminu (fsck). Jeśli przechowujesz własną niezależną mapę wolnych bloków dla każdego podwoluminu, wówczas procedurę sprawdzania woluminu logicznego można skutecznie zrównoleglić. Innymi słowy, woluminy logiczne obsługiwane przez menedżerów wysokiego szczebla lepiej się skalują.
Ponadto w przypadku menedżerów woluminów niskiego poziomu nie będzie można organizować pełnoprawnych migawek. W przypadku systemów plików typu LVM i ZFS można wykonywać tylko migawki lokalne, ale nie migawki globalne. Lokalne migawki umożliwiają natychmiastowe wycofanie tylko zwykłych operacji na plikach. I nikt tam nie będzie cofał operacji na woluminach logicznych (dodawanie/usuwanie urządzeń). Spójrzmy na to na przykładzie. W pewnym momencie, gdy masz wolumin logiczny dwóch urządzeń A i B zawierający 100 plików, robisz migawkę systemu S, a następnie tworzysz kolejne sto plików.
Następnie dodajesz urządzenie C do woluminu i na koniec przywracasz system do migawki S. Pytanie: Ile plików i urządzeń zawiera twój wolumin logiczny po przywróceniu stanu do S? Plików będzie jak można się domyślić 100, ale będą 3 urządzenia - są to te same urządzenia A, B i C, chociaż w momencie tworzenia migawki w systemie były tylko dwa urządzenia (A i B ). Operacja dodawania urządzenia C nie została wycofana, a jeśli teraz usuniesz urządzenie C z komputera, spowoduje to uszkodzenie danych, więc przed usunięciem będziesz musiał najpierw wykonać kosztowną operację, aby usunąć urządzenie z woluminu logicznego ponownego zrównoważenia, co rozproszy wszystkie dane z urządzenia C do urządzeń A i B. Gdyby jednak Twój system FS obsługiwał globalne migawki, takie przywracanie równowagi nie byłoby wymagane, a po natychmiastowym przywróceniu do S można bezpiecznie usunąć urządzenie C z komputera.
Tak więc migawki globalne są dobre, ponieważ pozwalają uniknąć kosztownego usuwania (dodawania) urządzenia z woluminu logicznego (do woluminu logicznego) z dużą ilością danych (oczywiście, jeśli pamiętasz o „migawce” systemu we właściwym czasie). Przypominam, że tworzenie migawek i przywracanie do nich systemu plików to operacje błyskawiczne. Może pojawić się pytanie: jak w ogóle możliwe jest natychmiastowe wycofanie operacji na woluminie logicznym, która zajęła Ci trzy dni? Ale to możliwe! Pod warunkiem, że system plików jest poprawnie zaprojektowany. Na pomysł takich „migawek 3D” wpadłem trzy lata temu, a w zeszłym roku opatentowałem tę technikę.
Następną rzeczą, której lokalne systemy plików powinny uczyć się od sieciowych systemów plików, jest przechowywanie metadanych na oddzielnych urządzeniach w taki sam sposób, w jaki sieciowe systemy plików przechowują je na oddzielnych maszynach (tzw. Serwery metadanych). Istnieją aplikacje, które działają głównie z metadanymi i można je znacznie przyspieszyć, umieszczając metadane na drogich, wydajnych urządzeniach pamięci masowej. Przy kombinacji FS+LVM nie będziesz w stanie wykazać takiej selektywności: LVM nie wie, co znajduje się w bloku, który mu przekazałeś (zawarte tam dane lub metadane).
Nie odniesiesz zbyt wielu korzyści z wdrożenia własnego niskiego poziomu LVM w FS w porównaniu z kombinacją FS + LVM, ale to, co możesz zrobić bardzo dobrze, to zaśmiecić FS tak, że później praca z jego kodem stanie się niemożliwa. ZFS i Btrfs, które pospieszyły z urządzeniami wirtualnymi, są wyraźnymi przykładami tego, jak naruszenie warstw niszczy system pod względem architektonicznym. Więc po co to wszystko? Co więcej, nie ma potrzeby instalowania własnego niskiego poziomu LVM w systemie plików. Zamiast tego należy agregować urządzenia w woluminy logiczne na wysokim poziomie, tak jak robią to niektóre sieciowe systemy plików w przypadku różnych maszyn (węzłów magazynowania). To prawda, że \uXNUMXb\uXNUMXbrobią to obrzydliwie z powodu użycia złych algorytmów.
Przykładami absolutnie okropnych algorytmów są tłumacz DHT w systemie plików GlusterFS i tak zwana mapa CRUSH w systemie plików Ceph. Żaden z algorytmów, które widziałem, nie zadowalał mnie pod względem prostoty i dobrej skalowalności. Musiałem więc zapamiętać algebrę i wszystko wymyślić sam. W 2015 roku, eksperymentując z pakietami nad funkcjami skrótu, wymyśliłem i opatentowałem coś, co mi odpowiada. Teraz mogę powiedzieć, że próba wdrożenia tego wszystkiego w życie zakończyła się sukcesem. Nie widzę problemów ze skalowalnością w nowym podejściu.
Tak, każdy podwolumin będzie wymagał osobnej struktury, takiej jak superblok w pamięci. Czy to jest bardzo przerażające? Generalnie nie wiem, kto będzie „gotował ocean” i tworzył woluminy logiczne składające się z setek tysięcy lub więcej urządzeń na jednej lokalnej maszynie. Jeśli ktoś może mi to wyjaśnić, będę bardzo wdzięczny. Tymczasem dla mnie to marketingowy bełkot.
Jak zmiany w podsystemie urządzeń blokujących jądro (na przykład pojawienie się blk-mq) wpłynęły na wymagania dotyczące implementacji FS?
Nie miało to żadnego wpływu. Nie wiem, co powinno się wydarzyć na warstwie blokowej, co spowodowałoby konieczność zaprojektowania nowego FS. Interfejs interakcji tych podsystemów jest bardzo słaby. Od strony sterownika na FS powinno wpływać jedynie pojawienie się nowych typów napędów, do których najpierw będzie dopasowywana warstwa blokowa, a dopiero potem FS (dla reiser4 będzie to oznaczać pojawienie się nowych wtyczek).
Czy pojawienie się nowych typów nośników (na przykład SMR lub wszechobecność dysków SSD) oznacza zasadniczo nowe wyzwania w projektowaniu systemów plików?
Tak. I to są normalne bodźce do rozwoju FS. Wyzwania mogą być różne i zupełnie nieoczekiwane. Na przykład słyszałem o dyskach, w których prędkość operacji we/wy w dużym stopniu zależy od rozmiaru fragmentu danych i jego przesunięcia. W systemie Linux, gdzie rozmiar bloku FS nie może przekraczać rozmiaru strony, taki dysk domyślnie nie pokaże swoich pełnych możliwości. Jeśli jednak Twój system plików zostanie zaprojektowany poprawnie, istnieje szansa, że wydobędziesz z niego znacznie więcej.
Ile osób oprócz Ciebie pracuje obecnie z kodem Reiser4?
Mniej, niż bym chciał, ale nie odczuwam też dotkliwego niedoboru zasobów. Jestem więcej niż zadowolony z tempa rozwoju Reiser4. Nie mam zamiaru „prowadzić koni” – to nie ten teren. Tutaj „jeśli będziesz jechał ciszej, pojedziesz dalej!” Nowoczesny system plików to najbardziej złożony podsystem jądra, którego błędne decyzje projektowe mogą zniweczyć kolejne lata ludzkiej pracy.
Oferując wolontariuszy do wdrożenia czegoś, zawsze gwarantuję, że wysiłki z pewnością doprowadzą do prawidłowego rezultatu, który może być wymagany w przypadku poważnych potrzeb. Jak rozumiesz, nie może być wielu takich gwarancji na raz. Jednocześnie nie znoszę „figurek”, które bezwstydnie promują „cechy” oczywiście bezużytecznego oprogramowania, oszukując setki użytkowników i programistów, a jednocześnie siedzą i uśmiechają się na szczytach dotyczących jądra.
Czy jakakolwiek firma wyraziła chęć wsparcia rozwoju Reiser4?
Tak, były takie propozycje m.in. i od głównego dostawcy. Ale w tym celu musiałem przeprowadzić się do innego kraju. Niestety nie mam już 30 lat, nie mogę się oderwać i tak odejść po pierwszym gwizdku.
Jakich funkcji obecnie brakuje w Reiser4?
Nie ma funkcji „zmiany rozmiaru” dla prostych woluminów, podobnej do tej, którą można znaleźć w ReiserFS (v3). Poza tym operacje na plikach z flagą DIRECT_IO nie zaszkodzi. Następnie chciałbym móc podzielić wolumin na „semantyczne podwomy”, które nie mają stałego rozmiaru i które można zamontować jako niezależne woluminy. Zadania te są dobre dla początkujących, którzy chcą spróbować swoich sił w „prawdziwej rzeczy”.
I na koniec chciałbym mieć sieciowe woluminy logiczne z prostą implementacją i administracją (nowoczesne algorytmy już na to pozwalają). Ale tym, czego Reiser4 na pewno nigdy nie będzie miał, jest RAID-Z, zarośla, wolne pamięci podręczne, 128-bitowe zmienne i inne marketingowe bzdury, które powstały na tle braku pomysłów wśród twórców niektórych systemów plików.
Czy wszystko, co może być potrzebne, można zaimplementować za pomocą wtyczek?
Jeśli mówimy tylko o interfejsach i wtyczkach (modułach) je implementujących, to nie o wszystkim. Ale jeśli wprowadzisz także relacje na tych interfejsach, to między innymi będziesz miał koncepcje wyższych polimorfizmów, z którymi już możesz sobie poradzić. Wyobraź sobie, że hipotetycznie zamroziłeś obiektowy system wykonawczy, zmieniłeś wartość wskaźnika instrukcji, aby wskazywał inną wtyczkę, która implementuje ten sam interfejs X, a następnie odblokowałeś system, aby mógł kontynuować wykonywanie.
Jeśli użytkownik końcowy nie zauważy takiej „podstawienia”, to mówimy, że system ma polimorfizm zerowego rzędu w interfejsie X (lub system jest heterogeniczny w interfejsie X, co jest tym samym). Jeśli teraz masz nie tylko zbiór interfejsów, ale także masz na nich relacje (graf interfejsu), to możesz wprowadzić polimorfizmy wyższych rzędów, które będą charakteryzowały heterogeniczność systemu już w „sąsiedztwie” dowolnego interfejsu. Już dawno wprowadziłem taką klasyfikację, ale niestety nigdy do niej nie doszło.
Tak więc za pomocą wtyczek i takich wyższych polimorfizmów można opisać dowolną znaną funkcję, a także „przewidzieć” te, o których nawet nie wspomniano. Nie udało mi się tego ściśle udowodnić, ale nie znam jeszcze kontrprzykładu. Ogólnie rzecz biorąc, to pytanie przypomniało mi „Program Erlangen” Felixa Kleina. W pewnym momencie próbował przedstawić całą geometrię jako gałąź algebry (w szczególności teorii grup).
A teraz zasadnicze pytanie - jak idzie sprawa z awansem Reiser4 na główny rdzeń? Czy były jakieś publikacje na temat architektury tego systemu plików, o których wspominałeś w ostatnim wywiadzie? Jak istotne jest to pytanie z Twojego punktu widzenia?
W sumie o włączenie do gałęzi głównej zabiegaliśmy od trzech lat. Ostatni komentarz Reisera w wątku publicznym, w którym złożono prośbę o ściągnięcie, pozostał bez odpowiedzi. Zatem wszelkie dalsze pytania nie są do nas. Osobiście nie rozumiem, dlaczego musimy „scalić się” z konkretnym systemem operacyjnym. W systemie Linux światło nie zbiegało się jak klin. Istnieje zatem osobne repozytorium, w którym będzie kilka portów rozgałęzień dla różnych systemów operacyjnych. Ktokolwiek tego potrzebuje, może sklonować odpowiedni port i zrobić z nim, co chce (oczywiście w ramach licencji). Cóż, jeśli ktoś tego nie potrzebuje, to nie mój problem. W tym miejscu proponuję uznać kwestię „awansu do głównego jądra Linuksa” za rozstrzygniętą.
Publikacje na temat architektury FS są istotne, ale jak dotąd znalazłem czas tylko na moje nowe wyniki, które uważam za wyższy priorytet. Inna sprawa, że jestem matematykiem, a w matematyce każda publikacja jest streszczeniem twierdzeń i ich dowodów. Publikowanie tam czegokolwiek bez dowodu jest oznaką złego smaku. Jeśli dokładnie udowodnię lub obalę jakiekolwiek twierdzenie na temat architektury FS, efektem będą takie stosy, przez które będzie dość trudno się przebić. Kto tego potrzebuje? Prawdopodobnie dlatego wszystko nadal pozostaje w swojej starej formie - kod źródłowy i komentarze do niego.
Co nowego w Reiser4 na przestrzeni ostatnich kilku lat?
Długo oczekiwana stabilizacja wreszcie nadeszła. Jednym z ostatnich, który się pojawił, był błąd, który powodował, że katalogi były „nieusuwalne”. Trudność polegała na tym, że pojawiał się on jedynie na tle kolizji skrótów nazw i przy określonej lokalizacji rekordów katalogu w węźle drzewa. Jednak nadal nie mogę polecić Reiser4 do produkcji: w tym celu musisz popracować nad aktywną interakcją z administratorami systemu produkcyjnego.
W końcu udało nam się wdrożyć nasz wieloletni pomysł - różne modele transakcji. Wcześniej Reiser4 obsługiwał tylko jeden zakodowany na stałe model Macdonalda-Reisera. Stworzyło to problemy projektowe. W szczególności w takim modelu transakcyjnym nie są możliwe migawki - zostaną one uszkodzone przez komponent atomowy o nazwie „OVERWRITE SET”. Reiser4 obsługuje obecnie trzy modele transakcji. W jednym z nich (Write-Anywhere) komponent atomowy OVERWRITE SET zawiera jedynie strony systemowe (obrazy bitmap dysku itp.), których nie można „sfotografować” (problem kury i jajka).
Dzięki temu zdjęcia można teraz zrealizować w najlepszy możliwy sposób. W innym modelu transakcyjnym wszystkie zmodyfikowane strony trafiają jedynie do ZESTAWU OVERWRITE (czyli jest to w zasadzie czyste kronikowanie). Ten model jest dla tych, którzy narzekali na szybką fragmentację partycji Reiser4. Teraz w tym modelu twoja partycja będzie fragmentować nie szybciej niż w przypadku ReiserFS (v3). Wszystkie trzy istniejące modele, z pewnymi zastrzeżeniami, gwarantują atomowość operacji, ale przydatne mogą być także modele z utratą atomowości i zachowaniem jedynie integralności przekroju. Takie modele mogą być przydatne we wszelkiego rodzaju aplikacjach (bazy danych itp.), które przejęły już część tych funkcji. Dodanie tych modeli do Reiser4 jest bardzo proste, ale ja tego nie zrobiłem, bo nikt mnie o to nie prosił, a mi osobiście jest to niepotrzebne.
Pojawiły się sumy kontrolne metadanych, które ostatnio uzupełniłem o „ekonomiczne” lustra” (materiał wciąż niestabilny). Jeśli suma kontrolna dowolnego bloku nie powiedzie się, Reiser4 natychmiast odczytuje odpowiedni blok z urządzenia repliki. Pamiętaj, że ZFS i Btrfs nie mogą tego zrobić: projekt na to nie pozwala. Tam należy uruchomić specjalny proces skanowania w tle zwany „scrub” i poczekać, aż dotrze do problematycznego bloku. Programiści w przenośni nazywają takie zdarzenia „kulami”.
I wreszcie pojawiły się heterogeniczne woluminy logiczne, oferujące wszystko, czego w zasadzie nie mogą zapewnić ZFS, Btrfs, warstwa blokowa, a także kombinacje FS+LVM - skalowanie równoległe, alokator adresów dyskowych O(1), przezroczysta migracja danych pomiędzy podwoluminami. Ten ostatni posiada również interfejs użytkownika. Teraz możesz łatwo przenieść najgorętsze dane na dysk o najwyższej wydajności w swoim wolumenie.
Ponadto możliwe jest pilne zrzucenie na taki dysk wszelkich brudnych stron, co znacznie przyspiesza działanie aplikacji często wywołujących fsync(2). Zwracam uwagę, że funkcjonalność warstwy blokowej zwana bcache w ogóle nie zapewnia takiej swobody działania. Nowe woluminy logiczne oparte są na moich algorytmach (istnieją odpowiednie patenty). Oprogramowanie jest już dość stabilne, można je wypróbować, zmierzyć wydajność itp. Jedyną niedogodnością jest to, że na razie trzeba ręcznie zaktualizować konfigurację woluminu i gdzieś ją zapisać.
Dotychczas udało mi się zrealizować swoje pomysły w 10 procentach, udało mi się jednak to, co wydawało mi się najtrudniejsze - połączenie woluminów logicznych procedurą flash, która wykonuje wszystkie odroczone akcje w reiser4. To wszystko nadal znajduje się w eksperymentalnej gałęzi „format41”.
Czy Reiser4 przechodzi testy xfstest?
Przynajmniej tak było w moim przypadku, gdy przygotowywałem ostatnią wersję.
Czy w zasadzie możliwe jest uczynienie Reiser4 sieciowym (klastrowym) FS za pomocą wtyczek?
Jest to możliwe, a nawet konieczne! Jeśli utworzysz plik sieciowy w oparciu o odpowiednio zaprojektowany lokalny system plików, efekt będzie naprawdę imponujący! W nowoczesnych sieciowych systemach plików nie jestem usatysfakcjonowany obecnością poziomu pamięci masowej zaplecza, który jest realizowany przy użyciu dowolnego lokalnego systemu plików. Istnienie tego poziomu jest całkowicie nieuzasadnione. Sieciowy system FS musi bezpośrednio współdziałać z warstwą blokową i nie może prosić lokalnego FS o utworzenie jakichkolwiek innych plików usług!
Ogólnie rzecz biorąc, podział systemów plików na lokalne i sieciowe jest od złego. Wynikało to z niedoskonałości algorytmów, które stosowano trzydzieści lat temu i zamiast których nie zaproponowano jeszcze nic. Jest to również powód pojawienia się masy niepotrzebnych komponentów oprogramowania (różne usługi itp.). W dobrym tego słowa znaczeniu powinien być tylko jeden FS w postaci modułu jądra i zestawu narzędzi użytkownika zainstalowanych na każdej maszynie - węzeł klastra. Ten system plików jest zarówno lokalny, jak i sieciowy. I nic więcej!
Jeśli z Reiser4 na Linuksie nic nie wyjdzie, chciałbym zaproponować FS dla FreeBSD (cytat z poprzedniego wywiadu: „...FreeBSD... ma korzenie akademickie... A to oznacza, że z dużym prawdopodobieństwem będziemy znajdzie wspólny język z twórcami”) ?
Jak więc właśnie się dowiedzieliśmy, z Linuksem wszystko już działało idealnie: istnieje dla niego oddzielny działający port Reiser4 w postaci głównej gałęzi naszego repozytorium. Nie zapomniałem o FreeBSD! Oferta! Jestem gotowy do ścisłej współpracy z tymi, którzy dobrze znają FreeBSD od środka. Swoją drogą: w ich społeczności bardzo podoba mi się to, że decyzje podejmuje zaktualizowana rada niezależnych ekspertów, co nie ma nic wspólnego z oszukiwaniem przez rząd jednej stałej osoby.
Jak oceniasz dzisiejszą społeczność użytkowników Linuksa? Czy stało się bardziej „popowe”?
Biorąc pod uwagę charakter mojej pracy, dość trudno mi to ocenić. Przeważnie użytkownicy przychodzą do mnie z raportami o błędach i prośbami o naprawienie tej sekcji. Użytkownicy jako użytkownicy. Niektórzy są bardziej bystrzy, inni mniej. Każdy jest traktowany tak samo. Cóż, jeśli użytkownik zignoruje moje instrukcje, to przepraszam: polecenie ignorowania zostanie wprowadzone również z mojej strony.
Czy można przewidzieć rozwój systemów plików na najbliższe pięć do dziesięciu lat? Jak myślisz, jakie są główne wyzwania, przed którymi mogą stanąć programiści FS?
Tak, sporządzenie takiej prognozy nie jest trudne. Już od dłuższego czasu nie rozwijano systemów plików wyższego szczebla. Tworzony jest jedynie wygląd takiego. Twórcy lokalnych systemów plików napotkali problemy związane ze złym projektem. Należy tu poczynić pewne zastrzeżenie. Nie uważam tzw. „przechowywania”, „lizania” i przenoszenia kodu za rozwój i rozwój. I nie klasyfikuję nieporozumienia zwanego „Btrfs” jako rozwoju z powodów, które już wyjaśniłem.
Każda łatka tylko pogarsza problemy. Dobrze. i zawsze są różnego rodzaju „ewangeliści”, dla których „wszystko działa”. Zasadniczo są to uczniowie i studenci opuszczający wykłady. Wyobraź sobie: jemu to działa, ale profesorowi nie. Cóż to za adrenalina! Z mojego punktu widzenia największą krzywdę wyrządzają „rzemieślnicy”, którzy rzucili się do entuzjastycznego „wkręcania” wspaniałych funkcji Btrfs na wszelkiego rodzaju warstwy, takie jak systemd, docker itp. - to już przypomina przerzuty.
Spróbujmy teraz sporządzić prognozę na pięć do dziesięciu lat. Opisałem już pokrótce, co będziemy robić w Reiser4. Głównym wyzwaniem dla lokalnych deweloperów FS z upstreamu będzie (tak, już się stało) niemożność wykonania przyzwoitej pracy za wynagrodzenie. Bez żadnych pomysłów w zakresie przechowywania danych, będą nadal próbować łatać te niefortunne VFS, XFS i ext4. Sytuacja z VFS wygląda na tym tle szczególnie komicznie, przypominając szaleńczą modernizację restauracji, w której nie ma szefów kuchni i od kucharzy się nie oczekuje.
Teraz kod VFS, bez żadnych warunków, blokuje kilka stron pamięci jednocześnie i zaprasza bazowy FS do działania na nich. Zostało to wprowadzone, aby poprawić wydajność Ext4 podczas operacji usuwania, ale jak łatwo zrozumieć, takie jednoczesne blokowanie jest całkowicie niezgodne z zaawansowanymi modelami transakcji. Oznacza to, że nie będzie można po prostu dodać obsługi jakiegoś inteligentnego systemu plików w jądrze. Nie wiem, jak jest w innych obszarach Linuksa, ale jeśli chodzi o systemy plików, rozwój tutaj raczej nie będzie zgodny z polityką Torvaldsa w praktyce (wyrzucane są projekty akademickie, a oszuści, którzy nie mam pojęcia, co to za drzewo B, wydawane są niekończące się kredyty zaufania). Dlatego opracowano kurs powolnego rozkładu. Oczywiście ze wszystkich sił będą starali się przedstawić to jako „rozwój”.
Co więcej, „opiekunowie” systemów plików, zdając sobie sprawę, że na samym „pamięci masowej” niewiele zarobisz, spróbują swoich sił w bardziej dochodowym biznesie. Są to z reguły rozproszone systemy plików i wirtualizacja. Być może przeniosą modny ZFS gdzieś indziej, gdzie jeszcze go nie ma. Ale to, jak wszystkie FS z góry, przypomina choinkę noworoczną: jeśli możesz powiesić na wierzchu inne drobne rzeczy, nie możesz zejść głębiej. Przyznam, że da się zbudować poważny system korporacyjny w oparciu o ZFS, ale skoro już rozmawiamy o przyszłości, to mogę tylko ze smutkiem stwierdzić, że ZFS jest pod tym względem beznadziejny: chłopaki za pomocą swoich wirtualnych urządzeń odcięli dopływ tlenu dla siebie i przyszłych pokoleń w celu dalszego rozwoju. ZFS to już przeszłość. A ext4 i XFS nie są nawet przedwczoraj.
Warto osobno wspomnieć o rewelacyjnej koncepcji „Linuxowego systemu plików nowej generacji”. Jest to projekt całkowicie polityczny i marketingowy, stworzony po to, aby, że tak powiem, „przypiąć przyszłość systemów plików” w Linuksie za konkretnymi znakami. Faktem jest, że Linux był kiedyś „tylko dla zabawy”. Ale teraz jest to przede wszystkim maszynka do robienia pieniędzy. Są wykonane na wszystkim, co możliwe. Na przykład bardzo trudno jest stworzyć dobre oprogramowanie, ale inteligentni „programiści” od dawna zdali sobie sprawę, że nie ma potrzeby się w ogóle męczyć: można z powodzeniem sprzedać nieistniejące oprogramowanie, które było ogłaszane i promowane na wszelkiego rodzaju publicznych wydarzenia - najważniejsze jest to, że slajdy prezentacji powinny zawierać więcej „funkcji”.
Systemy plików są do tego idealne, ponieważ możesz bezpiecznie targować się o wynik przez dziesięć lat. Cóż, jeśli ktoś później narzeka na brak tego właśnie wyniku, to po prostu nic nie rozumie o systemach plików! Przypomina to piramidę finansową: na szczycie znajdują się poszukiwacze przygód, którzy wszczęli ten bałagan, oraz ci nieliczni, którym „szczęściło się”: „wycofali dywidendy”, tj. otrzymywał pieniądze na rozwój, dostał dobrze płatną pracę na stanowisku menadżerskim, „pojawiał się” na konferencjach itp.
Następni są ci, którzy mają „pecha”: policzą straty, poradzą sobie z konsekwencjami wdrożenia bezużytecznego oprogramowania do produkcji „itd. Jest ich o wiele więcej. Cóż, u podstawy piramidy znajduje się ogromna masa programistów „piłujących” bezużyteczny kod. To oni są największymi przegranymi, bo zmarnowanego czasu nie da się zwrócić. Takie piramidy są niezwykle korzystne dla Torvaldsa i jego współpracowników. A im więcej tych piramid, tym lepiej dla nich. Aby nakarmić takie piramidy, do rdzenia można zabrać wszystko. Oczywiście publicznie mówią coś przeciwnego. Ale nie oceniam po słowach, ale po czynach.
Zatem „przyszłość systemów plików w Linuksie” to kolejne bardzo promowane, ale mało przydatne oprogramowanie. Po Btrfs z dużym prawdopodobieństwem miejsce takiej „przyszłości” zajmie Bcachefs, będący kolejną próbą przekroczenia warstwy blokowej Linuksa z systemem plików (zły przykład jest zaraźliwy). I co typowe: są te same problemy co w Btrfs. Podejrzewałem to od dawna, a potem jakoś nie mogłem się powstrzymać i zajrzałem do kodu - to prawda!
Autorzy Bcachefs i Btrfs tworząc swoje FS aktywnie korzystali ze źródeł innych osób, niewiele o nich wiedząc. Sytuacja bardzo przypomina dziecięcą zabawę „zepsuty telefon”. I z grubsza mogę sobie wyobrazić, jak ten kod zostanie zawarty w jądrze. Właściwie nikt nie zobaczy „grabi” (wszyscy na nie nadepną później). Po licznych sprzeczkach na temat stylu kodu, oskarżeniach o nieistniejące naruszenia itp., zostanie wyciągnięty wniosek na temat „lojalności” autora, tego, jak dobrze „komunikuje się” z innymi programistami i jak skutecznie to wszystko może następnie sprzedać korporacjom.
Efekt końcowy nikogo nie zainteresuje. Być może dwadzieścia lat temu byłbym zainteresowany, ale teraz pytania zostały postawione inaczej: czy uda się to wypromować, aby w ciągu najbliższych dziesięciu lat określone osoby mogły zostać zatrudnione. I, niestety, nie ma zwyczaju zastanawiać się nad efektem końcowym.
Ogólnie rzecz biorąc, zdecydowanie odradzam rozpoczynanie tworzenia systemu plików od zera. Bo nawet znaczące inwestycje finansowe nie wystarczą, aby za dziesięć lat uzyskać coś konkurencyjnego. Mówię oczywiście o poważnych projektach, a nie o tych, które mają zostać „wepchnięte” do jądra. Dlatego skuteczniejszym sposobem wyrażania siebie jest dołączenie do prawdziwych firm, takich jak my. Nie jest to oczywiście łatwe – ale tak jest w przypadku każdego projektu wysokiego szczebla.
Najpierw będziesz musiał samodzielnie pokonać problem, który zaoferuję. Następnie przekonany o powadze Twoich intencji, zacznę pomagać. Tradycyjnie korzystamy wyłącznie z własnych rozwiązań. Wyjątkiem są algorytmy kompresji i niektóre funkcje skrótu. Nie wysyłamy programistów na konferencje, a potem nie siadamy i nie łączymy cudzych pomysłów („może co się wydarzy”), jak to jest w większości startupów.
Wszystkie algorytmy opracowujemy sami. Obecnie interesują mnie algebraiczne i kombinatoryczne aspekty nauki o przechowywaniu danych. W szczególności ciała skończone, asymptotyka, dowód nierówności. Jest też praca dla zwykłych programistów, ale od razu ostrzegam: wszelkie sugestie, aby „spojrzeć na inny FS i zrobić to samo” są ignorowane. Trafią tam również łatki mające na celu ściślejszą integrację z Linuksem poprzez VFS.
Nie mamy więc grabieży, ale rozumiemy, gdzie musimy pójść i mamy pewność, że ten kierunek jest właściwy. To zrozumienie nie przyszło w postaci manny z nieba. Przypomnę, że mamy za sobą 29 lat doświadczenia programistycznego, dwa systemy plików napisane od podstaw. I tyle samo narzędzi do odzyskiwania danych. A to dużo!
Źródło: opennet.ru