Przekład refleksji Teodora Ts’o (Theodore Ts’o), twórcy systemu plików Ext4, na temat rozwoju ext4, systemu plików BcacheFS, jądra Linux, ZFS, kodeksu postępowania oraz systemów plików w ogóle:
O rozwoju ext4.
W każdą wersję jądra ext4 angażuje się ponad pół tuzina osób. Obecnie większość mojego czasu poświęcam na przegląd kodu, przeprowadzanie testów oraz poprawę aplikacji testowej {kvm,gce,qemu,android}-xfstests. I bardzo polegam na 2-3 innych programistach pracujących w SUSE i IBM, którzy pomagają mi w przeglądaniu kodu.
O BcacheFS
Szczerze mówiąc, bcachefs nie jest całkowicie samodzielnym projektem — na przykład, Kent był autorem 72% poprawek między wydaniami jądra 6.11 a 6.12, podczas gdy z 103 poprawek do ext4 w tym samym okresie, byłem autorem dokładnie 0%. Dzieje się tak, ponieważ twardo wierzę, że programowanie to sport zespołowy, a moją rolą jako lidera technicznego jest umożliwienie uczestnikom ext4 zrobienia wszystkiego, co możliwe, aby poprawić system plików. Organizujemy cotygodniowe konferencje, w których uczestniczy Derrick Wong, starszy programista XFS i były opiekun XFS — i, jak wiadomo, pomagałem mu w kwestiach testowania XFS, a Derrick pomagał mi w różnych kwestiach testowania ext4, nawet rozważał kilka poprawek do ext4. Współpracujemy ze sobą i to dobrze.
Pozwalam innym ludziom zdecydować, czy chcą zaufać swoim danym komuś, kto jest samotnym, utalentowanym programistą, który może być bardziej utalentowany niż ja, ale dam Wam wskazówkę — można "oszukiwać", przyciągając zespół do rozwiązania problemu. Nie trzeba tego robić samodzielnie. Oczywiście, do tego trzeba umieć wydobyć to, co najlepsze w innych, i trzeba pracować razem. A uprzejme traktowanie się nawzajem na listach dyskusyjnych zdecydowanie się przyda.
O jądrze, CoC, możliwościach i przyszłości ext4
Ext4 rzeczywiście zyskuje pewne nowe funkcje, ale są to te, które firmy są skłonne sfinansować, ponieważ opłacalność rozwoju funkcji ma sens z perspektywy kosztów i korzyści. Na przykład fscrypt i katalogi bez uwzględniania wielkości liter były funkcjami przydatnymi dla Androida i Chrome OS, które były sfinansowane, przynajmniej częściowo, przez te grupy deweloperów (Steam również obawiał się o uwzględnianie wielkości liter i wsparł jednego z inżynierów). Chcemy dodać wsparcie dla zapisu bez przerwy (untorn), ponieważ poprawi to wydajność baz danych na emulowanych blokowych urządzeniach w chmurze, gdzie można gwarantować 16k atomowych zapisów, co pozwoli wyeliminować podwójne buforowanie w MySQL i PostgreSQL.
(W rzeczywistości Amazon i Google mogą to zrobić w swoich własnych produktach baz danych, zakładając, jak działają Amazon EBS i Google Persistent Disk, ale chcemy zrobić to w bardziej ogólny sposób, który będzie bardziej wspierany w dłuższej perspektywie). Jest to mniej atrakcyjne niż rzeczy takie jak reflinks, ale uzasadnienie zwrotu z inwestycji jest znacznie łatwiejsze, zarówno dlatego, że koszty są niższe (mniej pracy do opracowania, testowania i kwalifikacji do wdrożenia korporacyjnego), jak i dlatego, że korzyści są znacznie łatwiejsze do oceny ilościowej. Rzeczy takie jak „mogę zaoszczędzić wynagrodzenie XX programistów przez pięć lat” są znacznie łatwiejsze do uzasadnienia dla tego rodzaju funkcji zwiększających wydajność.
W przeciwieństwie do tego, reflinks są zabawne, ale nie mogłem znaleźć klienta gotowego pokryć koszty rozwoju, ani firmy, która uważa, że ich klienci będą kupować więcej ich produktu, jeśli dodadzą reflinks do ext4. Może to brzmieć strasznie korporacyjnie, ale jest historia o tym, jak inżynierowie ZFS rozpoczęli projekt od zera, nie pytając o zgodę kierownictwa ani nie otrzymując sugestii od działu sprzedaży, i przedstawili Sun to, co tak naprawdę było dokonanym faktem.
Brzmi świetnie, ale jeśli pomyśleć, że na końcu Sun zaczęła tracić pieniądze, aż musiała sprzedać się innej firmie, a w rzeczywistości organizacja inżynieryjna wspierająca ZFS już nie istnieje. W mniej więcej tym samym czasie, gdy ogłoszono ZFS, uczestniczyłem w badaniach w całej firmie dotyczących tego, czy warto inwestować w funkcje systemu plików dla AIX i Linux — i doszliśmy do wniosku, że nie, zwrot z inwestycji jest niewielki, a nowe funkcje systemu plików nie przyciągną większej liczby klientów kupujących sprzęt, oprogramowanie lub systemy IBM. Może dla IBM nastały trudne czasy, ale ona nadal istnieje, a Sun — nie.
W mniej więcej tym samym czasie przedstawiciele kilku firm zajmujących się Linuxem zebrali się, aby pomyśleć, jak Linux ma konkurować z ZFS. To na tym spotkaniu pojawiła się koncepcja, że btrfs będzie długoterminowym rozwiązaniem, a ext4 — krótkoterminowym rozwiązaniem, które zapewni wsparcie dla takich rzeczy jak zmiana rozmiaru w czasie rzeczywistym, 64-bitowe numery bloków oraz innych funkcji, które były w tradycyjnych systemach Unix i których brakowało w ext3.
Na tym spotkaniu poproszono mnie o określenie, co będzie potrzebne do stworzenia zupełnie nowego systemu plików. Przeprowadziłem badania, patrząc, ile wysiłku wymagało stworzenie takich systemów plików jak GPFS i JFS od IBM, advfs od Digital, oszacowałem, ile czasu zajęło Sun stworzenie ZFS i doprowadzenie tego systemu plików do stanu całkowicie gotowego do produkcji. Odpowiedź, którą otrzymałem, wynosiła około 100 osobolat, przy niskim szacunku wynoszącym 50 osobolat i wysokim szacunku 200 osobolat (ale to dotyczyło GPFS, które było klastrowym systemem plików, a więc znacznie bardziej skomplikowanym).
Poinformowałem o tym na spotkaniu, a pewien starszy inżynier z Intela powiedział: „Nie mówcie o tym kierownictwu, bo nigdy nie zatwierdzą projektu! Powiedzcie im, że btrfs będzie gotowe za 18 miesięcy”. Pozwalam ludziom decydować, kiedy btrfs osiągnie status „gotowości do użytku przedsiębiorstw”, zwłaszcza w przypadku nowych, atrakcyjnych, rozszerzonych funkcji, które miały konkurować z ZFS, ale nie sądzę, że można dyskutować o tym, że miało to miejsce nie za 18 miesięcy.
Nawet zanim Sun się rozpadła, wiele firm, które wysłały swoich przedstawicieli na spotkanie, zrezygnowało z udziału inżynierów w pracach nad btrfs, co z pewnością nie pomogło. Prawdopodobnie wynikało to z faktu, że firmy to racjonalne organizacje podejmujące własne decyzje o opłacalności inwestycji, a finansowanie nowego systemu plików nie miało sensu, jak mówienie ludziom, że Linux ma odpowiedź na ZFS.
Patrząc wstecz, można stwierdzić, że mimo iż ZFS miał naprawdę świetne funkcje, nie były one wystarczające, aby skłonić większość użytkowników do wyboru Solaris zamiast zakupu znacznie tańszych platform x86 i instalacji Linuxa. A kiedy Sun postanowił spróbować strategii OpenSolaris i Solaris x86, było już za późno. Efekty sieciowe były ogromne, a strategia x86 nie dawała odpowiedzi na pytanie, jak jedna firma, Sun, mogła płacić pensje wszystkim utalentowanym inżynierom pracującym nad Solaris. Zakup serwera x86 za 5000 dolarów nie zapewnia wielkiej rentowności sprzedaży w porównaniu z serwerem SunFire E10k Sparc za 100000 dolarów, który Sun nazywała „punktami” w „dot Com”.
Istota polega na tym, że działalność inżynierska w świecie rzeczywistym to kompromis, a realia biznesowe są częścią tego kompromisu. Nie przepraszam za to, że wolę jeść jedzenie i że chcę zarabiać wystarczająco dużo pieniędzy, aby pewnego dnia móc przejść na emeryturę. A to z kolei oznacza, że muszę dobrze rozumieć, jak przynoszę korzyści pracodawcy, przynajmniej w dziesięć razy większe niż moja pensja. Jeśli mogę to osiągnąć, kontynuując pracę z otwartym kodem i pomagając innym firmom zarabiać pieniądze, aby były gotowe do wkładu w ext4, cóż, to część wyzwania i powód, dla którego uwielbiam pracować z otwartym kodem.
Wracając do Kodeksu Postępowania, powiem, że niemal wszyscy główni twórcy systemów plików wsparli Kodeks nie z powodu jakichkolwiek słabych liberalnych przesłanek. To dlatego, że potrzebujemy każdego inżyniera, który jest gotów wnieść wkład w nasz projekt, a większość z nas widziała ludzi, którzy rezygnowali z pracy w Linuxie, przenosząc się na inne systemy operacyjne (znam jedną osobę, która przeszedł na Windows i była cennym deweloperem jądra Linux w IBM Linux Technology Center) lub pracowali nad wewnętrznymi projektami, ale nie nad tymi, które wymagały interakcji z LKML, z powodu toksycznego środowiska kilku osób na liście mailingowej.
W niektórych przypadkach obawy były bezpodstawne; na przykład Linus krzyczał na starszego programistę, który faktycznie powinien wiedzieć lepiej i z którym Linus spotykał się osobiście, a oni mieli już nawiązane relacje. Problem w tym, że nowi pracownicy nie wiedzieli o tym i byli przerażeni – 'a co, jeśli Linus upokorzy mnie publicznie, tak jak zrobił to ze Steve'em', nie rozumiejąc, że w praktyce tak się nie stanie. Dlatego mamy CoC; nie dla nas, starszych inżynierów, ale dla wspierania młodszych inżynierów w naszych zespołach, których chcemy szkolić, aby w pewnym momencie mogli zastąpić nas, gdy przyjdzie czas na emeryturę, lub gdy potrąci nas autobus, lub w jakiś inny sposób opuścimy ten świat.
Nie zapominajcie o 50-100 osobolat pracy nad stworzeniem systemu plików gotowego do użycia w środowisku korporacyjnym. Potrzebujemy wszystkich inżynierów, których możemy zaangażować, a wielu z nas wykonuje dodatkową pracę w wolnym czasie, ponieważ nie jest nam wszystko jedno. Tworzenie wysokiej jakości systemu plików to praca zespołowa i potrzebujemy każdego utalentowanego inżyniera, którego możemy zdobyć. Nawet jeśli jeden inżynier jest super 10-krotnym programistą, jeśli w efekcie odstraszy wielu innych inżynierów, którzy mogą pracować nad testami, optymalizacją wydajności itd., to po prostu nie warto pozwolić nikomu być łajdakiem.
Źródło: opennet.ru
