Dlaczego JFS jest tak niejasny?

Kiedy po raz pierwszy zacząłem używać Slackware lata temu, szybko nauczyłem się kochać JFS nad ext3 lub reiserfs, biorąc pod uwagę, że był niezawodny i jeśli nastąpiło nieczyste zamknięcie, jego sprawdzanie dysku było bardzo szybkie. Dopiero niedawno dowiedziałem się, że JFS jest niejasny do tego stopnia, że ​​prawie nikt go nie utrzymuje.

Nie miałem pojęcia, że ​​jestem w takiej mniejszości. Dlaczego tak się stało? Czy technologia systemu plików rozwinęła się do tego stopnia, że ​​JFS nie ma obecnie żadnych komparatywnych zalet? Czy to, że ext3 był bardziej interoperacyjny z innymi systemami operacyjnymi? Czy jakiś inny system plików został pobłogosławiony przez konkretnego dostawcę lub deweloperów jądra?

Nie tyle pytanie techniczne, co historyczne.

Pierwszą rzeczą, którą musisz usunąć, jest porównanie do ext [234] . Zastąpienie któregokolwiek z nich będzie przypominało zastąpienie NTFS w systemie Windows. Możliwe, jasne, ale zmiana będzie wymagać decyzji od góry.

Wiem, że pytasz o zachowanie istniejących alternatyw, a nie o usunięcie innych, ale ta uprzywilejowana konkurencja pochłania większość tlenu z pokoju. Dopóki nie pozbędziesz się konkurencji, marginalne alternatywy będą miały wyjątkowo trudny czas na zwrócenie uwagi.

Ponieważ ext [234] nie zniknie, JFS i jego podobne są od samego początku poważnie niekorzystni.

(To zjawisko nazywa się Tyrania domyślnego).

Po drugie, zarówno JFS, jak i XFS zostały wniesione do Linuksa mniej więcej w tym samym czasie i prawie rozwiązały te same problemy. Maniacy jądra mogą dyskutować o drobnych punktach między nimi, ale faktem jest, że ci, którzy natknęli się na jedno z ograniczeń ext [234] , mieli dwa mniej więcej równoważne rozwiązania w XFS i JFS.

Dlaczego więc wygrał XFS? Nie jestem pewien, ale oto kilka spostrzeżeń:

• Red Hat i SuSE poparły to.

  RHEL 7 używa XFS jako domyślnego systemu plików i była to opcja czasu instalacji w RHEL 6. Po wydaniu RHEL 6, Red Hat przeportował oficjalne wsparcie XFS na RHEL 5. XFS był dostępny dla RHEL 5 wcześniej przez pół-oficjalny Kanał EPEL .

  SuSE włączyło XFS jako opcję instalacji znacznie wcześniej niż Red Hat, wracając do SLES 8 , wydanej w 2002 roku. Nie jest to obecnie domyślna, ale oficjalnie była wspierana przez cały czas.

  Istnieje wiele innych dystrybucji Linuksa, a RHEL i SUSE nie są najbardziej popularne dystrybucje w całej przestrzeni Linux, ale nie są to wielkie żelazne dystrybucje wyboru. Grają tam, gdzie najważniejsze są zalety JFS i XFS. Firmy te nie zawsze mogą machać psem, ale w sprawach dotyczących dużego żelaza czasami mogą.

• XFS pochodzi z SGI , firmy, która zasadniczo zniknęła. Przed śmiercią oficjalnie zrzekli się wszelkich praw, jakie mieli w XFS, więc ludzie z Linuksa czuli się komfortowo, włączając je w jądro.

  IBM przyznał także JFS wystarczającą liczbę uprawnień, aby opiekunowie jądra Linuksa mogli swobodnie, ale nie możemy zapominać, że jest to aktywna, warta wiele miliardów dolarów firma z tysiącami patentów. Jeśli IBM kiedykolwiek zdecyduje, że jego wsparcie dla Linuksa nie jest już zgodne z jego zainteresowaniami, cóż, może stać się brzydkie.

  Pewnie, ktoś prawdopodobnie ma teraz prawa własności intelektualnej SGI i mógłby zrobić zamieszanie, ale prawdopodobnie nie okaże się to gorsze niż klęska SCO . IBM może ważyć nawet i pomoc w squash taki troll, ponieważ ich interesy zrobić obejmują obecnie wspiera Linuksa.

  Chodzi o to, że XFS po prostu czuje się bardziej „wolny” dla wielu ludzi. Jest mniej prawdopodobne, że spowoduje jakiś problem w przyszłości z IP. Jednym z problemów z naszym obecnym systemem IP jest to, że prawa autorskie są powiązane z okresem istnienia firmy, a firmy zwykle nie umierają. SGI zrobiła to. To sprawia, że ​​ludzie czują się lepiej, traktując wkład SGI w XFS tak jak wkład każdej osoby.

• W każdym systemie obejmującym efekty sieciowe, w którym masz dwie z grubsza równoważne alternatywy - w tym przypadku JFS i XFS - prawie nigdy nie dzielisz udziału w rynku 50/50.

  Tutaj efektami sieciowymi są trening, kompatybilność, dostępność funkcji ... Efekty te popychają równowagę coraz dalej w stronę opcji, która zapewniła to wczesne zwycięstwo. Zobacz Windows vs. OS X, Linux vs. all-other- * ix, Ethernet vs. Token Ring ...

Jako osoba, która intensywnie współpracowała z JFS w systemie Linux i zagłębiła się w kod źródłowy w celu rozwiązania problemów, mogę przyjąć kilka powodów:

1. JFS to port systemu plików utworzonego dla systemu AIX, a następnie przeniesiony do systemu OS / 2, a następnie otwarty. Nie działa na nim żaden programista systemu AIX, ponieważ istnieje ryzyko zanieczyszczenia kodu, a OS / 2 nie był rozwijany przez dłuższy czas.
2. Po przeczytaniu kodu i śledzeniu rozwoju JFS zauważyłem wiele problemów w kodzie (jednym z nich był błąd zmiany rozmiaru FS na maszynach big-endian, tj. Tych stworzonych przez IBM), które zostały naprawione przez projekt i nie były połączyło się z jądrem głównym nawet kilka miesięcy po poprawce, prawdopodobnie dlatego, że programiści IBM nie byli oficjalnie opiekunami tej części drzewa.
3. Kod ma wiele problemów z czytelnością, które prawdopodobnie przyczyniły się do braku oficjalnego wsparcia ze strony dystrybucji, ponieważ trudny do odczytania kod jest trudny do debugowania.
4. Zakładam, że jednym z głównych zastosowań na początku JFS dla Linuksa była migracja informacji i udostępnianie informacji systemom AIX, ale w AIX5L nie było (obsługiwanej) opcji korzystania z systemu plików na prostym dysku bez zastrzeżonej LVM używanej przez AIX, który nie był dostępny dla Linuksa, a JFS został rozszerzony bez tych rozszerzeń przeniesionych do Linuksa (patrz numer 1).

Wyjaśnienie: Mimo że w przeszłości pracowałem w IBM, nigdy nie byłem członkiem zespołu programistycznego IBM AIX ani zespołu programistycznego JFS, a te przypuszczalne przyczyny są oparte na mojej dedukcji logicznej i znajomości historii systemu plików i Linuksa.