Kernel Traffic #125 For 9 Jul 2001

Linux Test Project to projekt open source rozpoczęty przez SGI. Ostatnio do prac dołączyły się również IBM oraz OSDL. Celem projektu jest stworzenie zestawu narzędzi do testowania jądra Linuksa oraz ogólnie całego Linuksa. Projekt składa się z ponad 100 różnych testów i automatu, który je przeprowadza. Nowa wersja zawiera wiele nowych testów i uaktualnienia starszych.

• Ponad 20 testów na wydajność obsługi sieci, w szczególności na zdalne wołanie procedur, sieciowe systemy plików, rozgłaszanie i inne sieciowe polecenia.
• Pełna gama testów obejmujących wątki, pamięć, systemy plików i operacje We/Wy na dysku.
• Kilka testów na polecenia często używane w środowisku rozwijania aplikacji.

Linux Test Project możecie pobrać z SourceForge'a, ze strony http://sourceforge.net/projects/ltp. Więcej informacji na temat Linux Test Project znajduje się na głównej stronie projektu: http://ltp.sf.net.

IBM z przyjemnością oznajmia, że wersja 1.0.0 open source'owego projektu Journaled File System (JFS) -- wydajnego i skalowalnego systemu plików dla Linuksa -- ujrzała światło dzienne.

http://oss.software.ibm.com/jfs

JFS jest szeroko znany jako sprawdzony i wydajny system plików, udostępniający możliwość odtworzenia się po padzie systemu i możliwość obsługi ogromnych konfiguracji dyskowych. JFS jest oparty na sprawdzonej technologii systemu plików z księgowaniem i w swojej wersji open source'owej jest dostępny na różne systemy operacyjne takie, jak AIX i OS/2.

Pierwsza wersja JFS, wydana jako wolne oprogramowanie, pochodzi z 2 lutego 2000, była licencjonowana na podstawie GNU GPL i nosiła numer 0.0.1. Od tej pory, dzięki wsparciu od całej społeczności open source, JFS silnie się rozwijał. Dzięki współpracy tej społeczności z zespołem JFS mogliśmy dojść do dzisiejszego wydania. Przez cały ten czas, dzięki polityce ,,częstych i szybkich wydañ'', mieliśmy 37 kolejnych wersji JFS.

JFS dla Linuksa w wersji 1.0.0 współpracuje z jądrami 2.4.x i oferuje następujące zaawansowane cechy:

• Szybkie odtworzenie się po padzie systemu
• Księgowanie operacji dla zachowania spójności systemu plików
• Księgowanie jedynie metadanych
• Extent-based allocation
• Znakomita wydajność
• 64-bitowy system plików
• Skalowalność. Struktury danych są tak zaprojektowane, aby żadne ograniczenia nie wpłynęły na działanie systemu plików
• Zaprojektowany do pracy na systemach wieloprocesorowych, ale sprawdza się doskonale również na stacjach roboczych
• Całkowita zgodność z aktualnym jądrem -- nie trzeba żadnych dodatkowych zmian, poza prostym zaaplikowaniem łaty
• Szczegółowe HOWTO na temat tworzenia systemu plików JFS i używania go na partycjach /boot i /root z wykorzystaniem lilo
• Pełny zbiór programów narzędziowych dla systemu plików
• Zgodność z wersją JFS dla OS/2

Zespół JFS (Barry Arndt, Steve Best, Dave Kleikamp)

Z tego co zrozumiałem z listu Linusa na lkml, jest dość istotna różnica pomiędzy JFS i XFS:

JFS nie wymaga żadnych zmian w istniejącym kodzie jądra, to jest tylko dodanie paru nowych rzeczy.

XFS przeciwnie, znacznie ingeruje w kod jądra.

Wobec tego, nawet jeśli JFS ma znacznie mniejszą funkcjonalność niż XFS (na przykład brak ACL-i i quoty) i nawet jeśli jest mniej stabilny niż XFS (nie wiem czy jest -- do tej pory używałem jedynie XFS i ext3), to włączenie go do jądra jest dużo prostsze i nie widzę żadnych (technicznych) przesłanek, aby go nie włączać.

Także włączenie ext3 do jądra nie powinno nastręczać problemów, bo a) kolesie pracujący nad ext3 to weterani lk oraz b) Redhat (a także VA) włączają obsługę ext3 w jądra dystrybucyjne (rawhide i aktualizacja 7.1).

Pozostaje mieć nadzieję, że mądrzy ludzie z SGI wymyślą sposób na przygotowanie łat, który spodoba się Linusowi, bo teraz plik ,,patch-2.4.5-xfs-1.0.1-core'' (który zawiera konieczne modyfikacje jądra) liczy sobie około 174090 bajtów.

Chciałbyś misiu.

Ale to nie tak.

Prześledź emaile z listy, które miały cc do Ciebie.

pre2 było w porządku, pre3 -- nie.

ac12 było w porządku, ac13 -- nie. pre3 z page_launderem z pre2 było w porządku.

I nie ma żadnych wątpliwości co do tego. Łata, która spowodowała problem została wycofana. Proszę -- nie mąćcie już więcej w tej kwestii.

Powiedziałem, że -ac13 miało problem, ale ac13 było tak naprawdę w porządku. Chodziło o ac14.

Zauważ też, że Alan włączył łaty MM w odwrotnej kolejności niż miało to miejsce w serii preX: w serii -ac, łata Rika do page_launder() została włączona w -ac14, podczas gdy moje zmiany w obsłudze VM zostały włączone w -ac15. W mojej gałęzi było inaczej: moje zmiany weszły w -pre2, a Rika -- w -pre3. W obu przypadkach moment zmiany page_launder() był momentem, w którym zaczęły powstawać problemy.

Dodatkowo w gałęzi -ac, ta zmiana nie interferowała z innymi i tylko ona została wycofana w -pre7.

Aby się dodatkowo upewnić, Timp <tcm@nac.net> przeprowadził testy z różnymi jądrami pre i nieoficjalnymi kombinacjami. Dzięki.

Chciałbym, żeby ktoś z was przejął opiekę nad NWFS. Rozwiązałem TRG, moją firmę zajestrowaną w Utah i teraz skupiam się na różnych projektach dla różnych klientów, związanych jakoś z rozwijaniem Linuksa. Novell ostatnio straszył mnie, że zabierze mój dom i inne dobra jeśli wypuszczę jeszcze jedną wersję NWFS albo MANOS.

Moje projekty konsultingowe idą całkiem dobrze, ale, mówiąc uczciwie, moja rodzina bardzo cierpiała przez ostatnie cztery lata walki z Novellem i jest duża szansa, że przeniosę interes do Nowego Meksyku lub Arizony, bo oni trzymają w garści wszystkie lokalne sądy w Utah (wszyscy sędziowie w Utah Valley są mormonami i trzymają stronę Novella).

Jest parę rzeczy, które wymagają przekształcenia i pracy, ja mogę odpowiadać na pytania i być technicznym konsultantem, ale nie mogę dłużej wypuszczać wersji NWFS dla Linuksa. Moje dzieci potrzebują dachu nad głową, a ja wierzę w to co Novell mówi o wyrzuceniu nas na bruk. Rynek ich ostatnio pokarał i są bardzo niebezpieczni, więc staram się schodzić im z drogi. Możecie oczywiście zrezygnować z projektu, ale może znajdzie się ktoś kto go przejmie.

Jeśli będziecie chcieli, żeby ktoś się tym zajął, moi pełnomocnicy przygotują ugodę przekazującą prawną własność na kogoś z Was. Zatrzymam M2FS i wersję klastrową, bo mam klientów za granicą, którzy potrzebują tej technologii, a nie wykorzystuje ona technologii specyficznych dla NetWare. Chciałbym zachować też prawa IP do NWFS.

Naprawdę, nie chcę patrzeć jak NWFS upada i nie jest obsługiwany, więc bardzo chciałbym, żeby ktoś się nim zajął i żeby nadawał się kiedyś do włączenia do 2.4

Obecnie w Linuksie, kiedy pewien kontekst jest usuwany, bo nowy jest potrzebny, a wszystkie są używane, wszystkie segementy MMU posiadane przez ten kontekst są zwalniane.

To nie jest właściwe, bo jeśli kontekst ma ograniczone zasoby pamięci to przy zmianie kontekstu wykonuje się wiele odwołañ do pamięci zakoñczonych niepowodzeniem i odbywa się to bez wyraźnego powodu.

Rozwiązanie polega na podłączeniu struktur danych opisujących stan MMU do mm_struct. W momencie gdy 'mm' przechodzi w kontekst hw, jeśli jakikolwiek segment MMU pozostaje na liście mm, jest wrzucana z powrotem do MMU.

Wydawało mi się, że ponownie raportujesz symbole konfiguracyjne, o które użytkownik nie może być zapytany - są one włączone tylko jako zależności albo ,,ifdefy'' w kodzie, nie jako wybieralne opcje.

Po dłuższym dochodzeniu wyszło mi, że nie miałem racji. Przepraszam za oskarżenia.

Tak naprawdę, wydaje mi się, że sporo kodu związanego z MIPSem zostało włączonego do -pre9 i te opcje _są_ teraz wybieralne, nie są tylko określeniem zależności, tak jak to było w części mojego kodu.