Kernel Traffic #160 For 2002/04/01

There were 465 different contributors. 233 posted more than once. 192 posted last week too.

David Schwartz spytał, czy ktoś pracuje nad obsługą zabezpieczeń sesji BGP przez opcję podpisów MD5 protokołu TCP w Linuksie. Dodał: "Jestem tym zainteresowany, bo chciałbym, aby Zebra mogła wykonywać bezpieczne połączenia BGP i chciałbym napisać łatkę dla Zebry z obsługą tego pod Linuksa." Alan Cox odrzekł: "Ponieważ, gdy ten dokument powstał po raz piewszy (pod inną nazwą), algorytm MD5 nie był odporny na ataki wyszukiwania kolizji [Dobb], to jest przez wiele osób uważany za niedostatecznie silny do tego typu zastosowań." David S. Miller użył mocniejszych słów:

Nie ma powodu, aby nie robić tych śmieci MD5 w przestrzeni użytkownika. Jeśli ktoś pomyślał, że to powinno się robić w samym protokole, musiał się czegoś napalić.

A jeśli ludzie chcą szyfrowania, powinni używać ipsec. A jeśli ipsec źle działa, to powinien zostać naprawiony ze względu na dodanie nowego obrzydlistwa do MD5.

Może czegoś nie zauważam, ale nie widzę powodu, dla którego MD5 miałoby należeć do protokołu, a nie do aplikacji.

Alan dodał, że nawet w przestrzeni użytkownika MD5 nie było najlepszym wyborem. Powiedział: "Ludzie od szyfrowania wolą SHA z określonych względów." David Schwartz odparł:

Nie ma problemu z MD5, który by czynił ten algorytm nieodpowiednim dla tego konkretnego zastosowania. Podpis SHA zwiększyłby rozmiar każdego pakietu, co spowodowałoby zmniejeszenie rzeczywistego MTU. To z kolei zwiększyłoby koszt tego, co było pomyślane jako prosty mechanizm rozwiązania określonego problemu (spoofowane ramki SYN i RST).

Problem sprowadza się do tego, czy zależy Wam na tym, żeby Linux mógł współpracować ze schematem uwierzytelniania BGP Cisco. Byłoby to dla mnie bardzo użyteczne, więc osobiście mi na tym zależy, nawet jeśli schemat nie jest najlepszym z możliwych.

David S. Miller odpowiedział, że ignorowanie poprawnych ramek RST będzie gwałciło TCP, ale Alan dodał:

Jeśli nie mają poprawnej ramki MD5, nie są poprawne. To RFC pojawiło się ponieważ ludzie odkryli, że spoofowanie RST ruterów cisco w sieci szkieletowej było znakomitym sposobem na usunięcie niechcianych ISP. Potem ludzie odkryli, że spoofowanie rozmiarów ramek icmp df do 68 bajtów dalej działało i cała ta sprawa z MD5 jest gówno warta.

Później ludzie od kryptografii pokazali, że MD5 nie zawsze jest wystarczająco dobre.

W końcu, jeśli jesteś cierpliwy i cholernie zdenerwowany, to możesz przechwycić sesje BGP, przewidując numer sekwencyjny, którego użyje drugi koniec następnym razem i zagrać w BGP.Na szczęście to jest niezwykle trudne.

IPSEC ma znacznie więcej zrobione w tym zakresie, ale większość urządzeń cisco obsługuje jedynie MD5. Jednakże, jeśli możesz odczytać/ustawić opcje IP/TCP w przestrzeni użytkownika, możesz to zrobić w ten sposób.

David S. Miller odpowiedział: "Jeśli mam być szczery, to nie obchodzi mnie co Cisco robi, a czego nie robi. Nie obchodzi mnie, że Cisco podjęło błędne decyzje. Nie chcę dopuścić do tego, aby wyniki błędów Cisco napiętnowały obsługę sieci w Linuksie." Powiedział, że argument Alana o tym, że ramki są tak naprawdę niepoprawne nie jest w porządku. Podpisy MD5, jak kontynuował, zdecydowanie gwałciły prostotę i klarowność dla RST, które są potrzebne, aby te ramki działały poprawnie. Z tego powodu w ramkach RST są wyłączone znaki czasowe PAWS, jak również inne sprawdzenia. Weryfikowany jest jedynie numer sekwencyjny. Nie ma więc sensu mówić o tym, że ramki są niepoprawne dlatego, że nigdy się w nich nie użyje podpisu MD5.

Alanowi wydało się, że David pieprzy trzy po trzy i rzekł: "Nie mówię, że RFC jest dobrym pomysłem (jednakowoż potrzeba tej łaty, aby użyć Linuksa w sieci szkieletowej razem z zestawami BGP większości producentów). Twój argument na temat ramek RST jest wart tyle co kupa łajna." Ale David S. Miller skontrował: "Popatrz, TCP to ostatnie miejsce, gdzie potrzebujemy złożoności. Z błędami w logice TCP radzimy sobie kończąc połączenie i wysyłając RST, a to musi być zrobione w prosty i łatwy do zweryfikowania sposób."

Alan cały czas się z tym nie zgadzał, ale powiedział: "Właściwie to mam bardziej konstruktywną propozycję dla ludzi od zebry. Rutujcie te śmieci z BGP przez urządzenie netlink tap, przemielcie w obie strony ramki tcp, ale w przestrzeni użytkownika. Dzięki temu nie będziecie musieli implementować TCP w przestrzeni użytkownika, ani nie rozwalicie ślicznego stosu sieciowego Dave'a. Aby to wszystko pasowało, będziecie musieli jeszcze ubić obsługę SACK." A David S. Miller dodał: "Innym rozwiązaniem byłoby zaangażowanie do obróbki pakietów modułu netfiltra."

Alan sądził, że rozwiązanie Dave'a S. Millera będzie wystarczająco szybkie, jak na potrzeby Davida Schwartza, ale wtedy David S. Miller zamieszał: "Po przemyśleniu uważam, że pomysł z TAP jest lepszy, bo gwarantuje brak narzutu, o ile skonfigurujesz to tak, aby przechodziły przez niego tylko pakiety BGP (do tego służy alias na urządzeniu dummy)." Mike Fedyk wytknął, że to wcale nie będzie bardziej wydajne, bo "Będziesz musiał użyć netfiltra do zaznaczenia odpowiednich pakietów, aby przerutowały się do interfejsu dummy." Ale David S. Miller powiedział: "W Linuksie możesz przywiązywać gniazda do określonych urządzeń, a to nie wymaga netfiltra."

Ktoś spytał, jaka jest maksymalna możliwa liczba wątków w Linuksie. Nadawca zauważył blokady po stworzeniu około 250 czy 275 wątków i chciał zwiększyć ten limit. David Schwartz zasugerował naprawienie błędu, a nie tworzenie obejścia. Dodał: "Do żadnego zadania nie potrzebujesz tworzyć tylu wątków. Twórz wątki jedynie, aby cały czas zajmować procesor albo, aby wykonywać operacje WE/WY, które nie mogą być wykonane asynchronicznie." Davide Libenzi zasugerował użycie 'ulimit -u', aby zobaczyć liczbę dostępnych wątków w systemie, ale Bill Davidsen powiedział, że prawdziwym ograniczeniem jest wartość zapisana w /proc/sys/kernel/threads-max. James Bourne zauważył: "Jest jeszcze jedna rzecz, na którą trzeba zwrócić uwagę. Otóż przy używaniu wątków jesteś ograniczony przez 1024 wątki na proces. Istnieją łaty dla glibc, które zwiększają tę wartość (do 4096 lub 8192)." W pewnym momencie Peter Wæchtler dodał: "Jest jeszcze jedno ograniczenie: 2 MB mmap() stosu dla każdego wątku. Więc w systemach 32 bitowych, przy liczbie wątków większej niż 1024, kończy Ci się przestrzeń adresowa."

Michal Jaegermann spytał, jaki jest maksymalny rozmiar partycji dla ext2 i ext3. Miał różne problemy z partycjami o wielkości mniej więcej 2 terabajtów. Andreas Dilger odrzekł:

2TB to ograniczenie rozmiaru dla wszystkich urządzeń blokowych w jądrach 2.2 i 2.4. Bierze się ono z 2^32 * 512 bajtowych sektorów. Użycie urządzeń LVM czy MD nie pozwoli na ominięcie tego ograniczenia.

Krąży gdzieś łata, która rozszerza liczniki bloków do 64-bitowych liczb całkowitych (wysłał ją Jens Axboe i/lub Ben LaHaise) i sądzę, że przynajmniej część tej łaty jest już w 2.5. Jeśli jednak masz 64-bitowe liczniki bloków, są też inne zagwozdki na które się prędzej, czy później natkniesz -- 32-bitowe indeksy stron czy inne 32-bitowe przepełnienia przy obliczeniach w kodzie ext2. Na pewno jest twarde ograniczenie przy 16TB dla 4kB bloków w systemie plików ext2, ale sądzę, że będziesz miał problemy już przy 8TB, nawet jeśli usuniesz 2TB ograniczenie dla urządzeń blokowych.

Jest źle, bardzo źle. Jeśli prawo przejdzie w takiej formie jak ta zapisana, to wszelkie oprogramowanie będzie jego przedmiotem. Senator Hollings i jego starzy przyjaciele (i wszyscy, którzy myślą tak jak oni) potrzebują wskazówki. Powinni wyjść z biura.

(Z góry przepraszam, jeśli to nie dojdzie do was jako tekst. System, z którego zwykle korzystam, zepsuł się i jestem zmuszony do używania Winsukcs i Nutscrape do poczty.)

http://www.wired.com/news/politics/0,1283,51274,00.html

Oczywistym rozwiązaniem jest kontynuowanie wizji Richarda Stallmana: Rozprowadzajcie cały kod tylko w formie źródeł - nie dystrybuujcie binariów.

W ten sposób pliki źródłowe są chronione przez zasadę wolności słowa i twórca jest bezpieczny.

Użytkownik może zatem zrobić z kodem to co sama/sam chce.

Sądzę, że chociaż sporo ludzi myśli, że Richard jest paranoikiem, to jest on jednak człowiekiem bardziej godnym zaufania i lepszym prorokiem niż uważa większość ludzi ...

Florian Weimer odpowiedział: "Niestety, to działa tylko w Stanach. W innych krajach, które wezmą przykład z przywództwa Stanów Zjednoczonych w ograniczaniu konsumenta, wolność słowa podlega innym prawom. Zgadzam się jednak, że dystrybucje zawierające tylko źródła pozwolą uniknąć wielu problemów i są preferowane."

W pewnym momencie Andre Hedrick podał odnośnik do strony Declana McCullagha (Politech).

W innym miejscu Itai Nahshon zauważył: "Najgorsze zdarzy się, gdy ktoś opatentuje schemat ochrony kopii..." Alan Cox odparł: "Microsoft już tak robi." A Herman Oosthuysen odpowiedział "Prawo mówi, że taki schemat ochrony musi mieć otwarte źródła, nie ma więc płacenia M$. Podejrzewam, że jeśli to prawo przejdzie, to wielu Amerykanów dostroi się do europejskich treści. Powinno być to także korzystne dla Kanady i Meksyku. Może powinniśmy wspierać to prawo..." Ale Rik van Riel napisał:

Fakt, że kod źródłowy jest dostępny nie daje Ci prawa jego używania, jeśli jakaś firma ma patent na technologię ...

Mam nadzieję, że to prawo będzie tak przeszkadzało w USA, że reszta świata zobaczy dewastujące rezultaty, zanim zdąży przegłosować podobne ustawy.

Jeśli prawo będzie wymagało od ciebie używania tego, to M$ nie będzie miało możliwości czerpać korzyści z patentu. Jest wystarczająco dużo precedensów tego rodzaju, zatem będzie to wolne.

Cały pomysł zostaje jednak niepraktyczny, więc nawet gdy to przejdzie, będzie dość bez znaczenia dla wielu geeków.

To, czego przemysł muzyczny nie zrozumie, to fakt, że muzyka się nie sprzedaje, bo jest kiepska. Żadna kontrola tego nie zrekompensuje. Wszędzie śmieci... Być może powinniśmy wrócić do płyt winylowych, odgrywanych na nakręcanych adapterach z igłami z kolców róż. Będą one odtwarzać muzykę w sposób niezgodny ze sprzętem odtwarzającym CD i nikt nigdy nie będzie chciał ich kopiować...

Jim MacBaine spytał, czy jest działający sterownik ftape dla 2.4, a Mikael Pettersson odparł: "Ten zawarty w nowych jądrach 2.4 powinien działać dla większości urządzeń ftape. 2.5 ma mały, ale rozwiązywalny problem przy kompilacji z powodu zmiany interfejsu do virt_to_bus()." Dodał jeszcze: "Te sterowniki nie są zbyt popularne, ale cały czas używam mojego starego Seagate/Conner TR-3 na zdalnym serwerze."

Chciałem ogłosić, że jest już ukończony (tylko do odczytu) nowy sterownik NTFS 2.0.0 do jądra Linuksa (wcześniej NTFS TNG). W tej chwili jest dostępny jedynie w wersji do jądra 2.5.7 i będzie zgłoszony Linusowi do włączenia do 2.5, gdy tylko Linus wróci z wakacji.

Sterownik był testowany intensywnie i jak na razie przeżył wszystkie testy.

Jest w pełni zgodny z wywłaszczaniem jądra i z SMP. Powinien także działać na architekturach z dowolną kolejnością bajtów w słowie oraz na architekturach 32 i 64 bitowych. Tak naprawdę, to tylko ia32 została przestestowana i mogą być problemy z architekturami nie obsługującymi niewyrównanego dostępu do pamięci. Jacyś ochotnicy do architektur nie-ia32?

Nowy sterownik jest znacznie szybszy niż stary (~20% w moich testach), zużywa mniej czasu procesora i w ogóle jest lepszy niż stary. (-:

Sterownik może być kompilowany zarówno przy użyciu gcc-2.95 i gcc 2.96. gcc-3.x nie był testowany. (Jeśli ktoś będzie miał problemy przy kompilacji, zwłaszcza z gcc-2.95, proszę o informację, to poprawię te błędy ASAP!)

Aby wyprobówać sterownik, albo użyjcie BitKeepera do uzyskania klonu z repozytorium:

bk clone -q http://linux-ntfs.bkbits.net/ntfs-tng-2.5

Albo, jeśli już macie klon pochodzący z oficjalnego repozytorium jądra, możecie pobrać jedynie zmiany:

bk pull http://linux-ntfs.bkbits.net/ntfs-tng-2.5

A potem będąc wewnątrz katalogu z repozytorium, pobierzcie wszystkie pliki używając bk -r co -q.

Dla osób nie używających BitKeepera łaty do standardowego jądra 2.5.7 są tutaj:

http://www-stu.christs.cam.ac.uk/~aia21/linux/linux-2.5.7-ntfs-2.0.0.patch.bz2
(151kiB)

http://www-stu.christs.cam.ac.uk/~aia21/linux/linux-2.5.7-ntfs-2.0.0.patch.gz
(199kiB)

http://www-stu.christs.cam.ac.uk/~aia21/linux/linux-2.5.7-ntfs-2.0.0.patch
(796kiB)

Wreszcie osoby chcące przejrzeć kod źródłowy on-line, powinny skierować swoje przeglądarki pod adres:

http://linux-ntfs.bkbits.net:8080/ntfs-tng-2.5

Proszę wszystkich wystarczająco odważnych do używania takiego jądra, a kto używa też NTFS niech proszę spróbuje i da mi znać jeśli wystąpią jakieś problemy! - Dzięki!

Christoph Hellwig potwierdził, że łata skompilowała mu się przy użyciu gcc 2.95.2.

Gdzie indziej David Woodhouse zwrócił uwagę, że wszystkie architektury powinny obsługiwać niewyrówany dostęp, zatem troska Antona o to, że mogą być jakieś problemy z architekturami tego nie obsługującymi nie miała sensu. Ale Brad Boyer odparł: "Być może wszystkie architektury ,,powinny'', ale mogę cię zapewnić, że wiele z nich tego nie robi. Nie oglądałem wszystkich obecnych architektur, ale niektóre znaczące, jak na przykład nowiutkie IA64, tak samo jak niektóre starsze kości takie jak MIPS miały relatywnie skomplikowany kod get_unaligned(), którą to funkcję można znaleźć w odpowiednim katalogu include/asm-i<arch>, w pliku unaligned.h. Podejrzewam, że przynajmniej niektóre z nich pozwalają funkcji obsługującej wyjątki oszukać tę możliwość w programach z przestrzeni użytkownika, ale to nie jest coś, na co można pozwolić wewnątrz jądra." A Alan Cox odpowiedział:

Jądro zakłada i wymaga, żeby procesor obsługiwał błędy i poprawki wyrównania pamięci w przestrzeni jądra.

Tak jest zrobione, bo jest wiele przypadków, w których obiekt jest prawie zawsze wyrównany i jest szybciej założyć to wyrówanie, niż robić zamieszanie wokół każdego kawałka danych. To jest dobrze dostosowane, więc takie pułapki wyrównania nie powinny występować zbyt często.

Davis S. Miller zaaplikował łatę do ATM i zauważył: "ATM na gwałt potrzebuje opiekuna. Czy któryś z hakerów jądra chciałby się dowiedzieć, jak działa ATM? :-))))" Dave Jones spytał: "Czy przypadkiem nikt się tym nie opiekuje gdzieś poza głównym drzewem?" Ale David odpowiedział: "Jeśli tak się dzieje, to nie przysyłają mi ani łat, ani aktualizacji, co tak naprawdę oznacza, że opieki brak."

Jakiś czas temu zrobiłem długawe próby OSDB (osdb.sf.net) na PostgreSQL 7.2. Wszystko było uruchamiane na jądrze 2.5.6 + sterownik dc385x i z łatą futexes. Włączyłem też reiserfs, ale w 2.5.6 dawał oopsa przy montowaniu. Nie udało mi się uruchomić 2.5.7, ale uruchomiłem to jeszcze raz, gdy pojawiły się nowe interesujące jądra.

Sprzęt to: 2 x P3-450, 384Mb, 3 x 9Gb dysków Quantum na wewnętrznym aic7xxx (nowy sterownik). Oprócz ,,vmstat 1'', system nie był inaczej używany podaczas testów. Nie zostały zamontowane inne systemy plików na dysku z testową partycją. Liczby wydają się być całkiem spójne - jeśli różnią się więcej niż o 5%, to można je porównywać (nie, nie jestem statystykiem i nie mogę za to ręczyć).

Skrypty, których używałem, są dostępne na żądanie, ale z grubsza robią, co następuje:

zatrzymanie postgresa
umount
mkfs
mount
stworzenie katalogów z danymi postgresa
wystartowanie postgres (włączając w to stworzenie bazy danych)
"osdb-pg --datadir /scratch/data-40mb/ --short"

Symbole ustawień:
"dd" -- domyślny PG, default FS opts
"dn" -- domyślny PG, "noatime"
"bn" -- duże bufory PG, "noatime"

                PostgreSQL
        tuning?	single  ir      mx-ir   oltp    mixed-oltp
                (sec)   (tps)   (sec)   (tps)   (sec)
ext2    dd      1304.72 66.64   214.25  188.50  230.55
        dn      1288.31 65.93   209.57  234.08  213.75   
        bn      1283.50 77.90   1867.71 192.43  226.77

ext3    dd      1303.84 66.87   212.49  66.06   361.04
        dn      1288.03 64.62   209.27  111.41  278.54
        bn      1285.32 65.98   1996.41 90.05   307.79

ext3-wb dn      1291.68 66.06   209.94  138.25  242.28
        bn      1287.31 98.42   2149.38 125.13  236.02

jfs     dd      1308.97 66.82   212.59  117.28  273.08
        dn      1288.60 65.08   211.56  116.18  218.22
        bn      1279.89 81.00   2059.26 114.20  225.56

minix   dd      1305.26 67.38   207.74  193.90  228.81
        dn      1331.27 67.14   210.07  223.70  214.33
        bn      1299.24 89.58   1988.31 231.17  231.17

Moje wnioski:

Muszę spędzić więcej czasu na podkręcaniu postgresa, ale wyraźnie coś poszło tutaj źle -- test ,,agg_simple_report'' stał się wyjaśnieniem prawie wszystkich różnic.
,,noatime'' jest bardzo użytecznym przełącznikiem w tych okolicznościach.
Systemy plików z księgowaniem mają wymierną przewagę przy takim obciążeniu.

Pytania:

Czy jest coś jeszcze czego powinienem spróbować, jakieś opcje systemów plików, itp?
Co robi jfs w trakcie księgowania danych? Czy to jest ,,ordered'' lub ,,writeback'' w terminologii ext3? (zakładam, że w pełni księgowane dane dałbyby znacznie gorsze wyniki).

Andi Kleen zapytał, czy ext3 zawierał uporządkowane dane, a Matthew potwierdził: "Tia. Wszystko jest domyślne, no chyba, że inaczej zostało napisane." Andi zajęczał w tym samym liście: "Łał, minix jest szybszy niż ext2 @) To oczywiście wygląda dziwnie." A Matthew odpowiedział "Taa, też myślałam, że to trochę dziwaczne. Postgres wykonuje dużo fsync()ów, więc pomyślałem, że te niższe narzuty wygrały ze sprytniejszym projektem ext2. Wszystkie operacje WE/WY miały fsync, więc ten test mógł wykazać tylko wydajność pisania. " Andrew Morton odparł:

Dla obciążeń z intensywnymi fsyncami najlepszym trybem ext3 jest taki, gdzie data=journal. W ten sposób fsyncowi wystarczy jedno proste liniowe pisanie do dziennika.

Przy dużej liczbie danych miejsce na dziennik zostanie szybko wyczerpane, więc powinno być korzystne stworzenie potwornego dziennika, przy użyciu, powiedzmy, mke2fs -J 400.

Proszę. Test został zrobiony przy dzienniku 200Mb (partycja była tylko trochę większa niż 1Gb, a pliki z danymi bardzo urosły, więc nie odważyłem się ich powiększać).

        tuning? single  ir      mx-ir   oltp    mixed-oltp
                (sec)   (tps)   (sec)   (tps)   (sec)
ext3    bn      1285.32 65.98   1996.41 90.05   307.79
ext3-wb bn      1287.31 98.42   2149.38 125.13  236.02
ext3-jd bn      1306.90 72.07   1813.54 125.15  305.27

WE/WY to powinny być same pisania z fsync, więc nie jestem pewny jak to może świadczyć o fakcie, że zadania OLTP i OLTP + różne (głownie czytanie) dają inne liczby.

Będę próbował znaleźć czas na uruchomienie tych testów jeszcze raz jutro, by przekonać sam siebie, że to wszystko ma sens, ale liczby są zwykle dość stabilne.

Andrew był trochę zawiedziony i dodał: "Wydaje się, że to jest dość użyteczne i poprawne obciążenie, przy którym warto to optymalizować. Skorzystam zatem z twojej oferty i poproszę o te skrypty. " Matthew przesłał je.

Wróćmy do pierwotnej odpowiedzi Andi'ego; zapytał on czy Matthew mógłby także przetestować XFS (w innym miejscu poprosił o to jeszcze Florin Andrei). Matthew odpowiedział, "Jasne. Będę się starał zbudować bardziej interesujące jądro w tym tygodniu. ext2 z delalloc też może być zabawne. Czy znacie może jakąś prostą łatę, albo łaty, które umożliwią działanie reiserfs na 2.5.6? " Nie było odpowiedzi.

Andi, w tej samej odpowiedzi, w odniesieniu do konkluzji Matthew, że systemy plików z księgowaniem mają istotny narzut przy obciążeniach, które testował:

Normalnie (bez księgowania danych, noatime) systemy plików z księgowaniem nie powinny dawać żadnego narzutu przy obciążeniu bazą danych, bo pliki bazy danych powinny być prealokowane i baza danych powinna robić bezpośrednio WE/WE przez prealokowane bufory tak, że system plików nigdy nie zapisuje metadanych, z wyjątkiem dokonywanych co jakiś czas aktualizacji mtime inodów, w zależności od stosowanego przez bazę trybu synchronizacji (hmm, wydaje mi się, że opcje montowania nomtime lub verylazymtime lub alwaysasyncmtime powinny w tym pomóc)

To jest teoria, ale nie wydaje się, że to przypadek, który wystąpił w twoim teście. Sądzę więc, że twoje testy nie są zbytnio realistyczne.

Matthew odpowiedział: "Albo twoje założenie o bazie danych i systemach plików nie są prawdziwe w tym przypadku. " Kontynuował: "Postgres nie prealokuje plików z danymi. Oni są przekonani, że implementacja systemu plików nie jest ich sprawą, a ja jestem skłonny się z nimi zgodzić. Wolą fdatasync na plikach z danymi i (jak sądzę) O_DATASYNC dla ich plików dziennika, tam gdzie one są, ale nie sprawdzałem czy właśnie to robi moja binarka. " Andreas Dilger odpowiedział "Jeśli WE/WY normalnie używa sync, powinieneś rozważyć testowanie ext3 z ,,data=journal''. Chociaż wydaje się to niezgodne z intuicją, bo powoduje to dwukrotne zapisywanie danych na dysk, często może być szybsze w realnych, ,,wybuchowych'' środowiskach, bo WE/WY z sync idzie do dziennika w jednym zwartym pisaniu, a zatem może być bezpiecznie zapisywane asynchronicznie w stosunku do reszty systemu plików. Możesz także zrobić zewnętrzne urządzenie na dziennik, tak, żeby dziennik był na oddzielnym dysku i zapobiec w ten sposób w skakaniu między dziennikiem, a resztą systemu plików. " To miało ręce i nogi w opinii Matthew i wątek się zakończył.

mamy tu komputer, który zachowuje się bardzo dziwnie, w ciągu sekundy zegar zmienia się o około godzinę do przodu. W następnej ,,prawdziwej'' sekundzie czas jest z powrotem normalny.

Cóż, na początku myślałem, że to może być problem z X, ale po uruchomieniu pętli po ,,date'', wygląda mi na to, że zmieniany jest zegar systemowy. Potem pomyślałem, że przyczyną może być konflikt z zegarem sprzętowym, ale po przestawieniu zegara na czas systemowy problem nie zniknął.

Jedyny zegar, który nie jest zmieniany, to zegar czasu rzeczywistego (przynajmniej nie, gdy w pętli jest uruchamiany cat odpowiedniego pliku z proc).

Problem, który tu się pojawia jest taki, że te skoki czasu powodują uruchamianie screensavera z X (jest jeszcze parę innych, mniejszych problemów).

System to: Athlon 650 na płycie VIA, z jądrem linux-2.4.17 (nie łatanym)

Adam Johansson potwierdził: "To samo zdarzyło mi się na Athlonie 600 na chipsecie KM133. Miałem wtedy waniliowe 2.4.18, po zaktualizowaniu do 2.4.19, problem się więcej nie pojawił. " Ale Jim MacBaine dodał: "Doświadczyłem tych dziwnych aktywacji screensavera także z 2.4.19-pre2-ac4."

W innym miejscu także Mark Cooke odpowiedział na pierwszą wiadomość Bernda, mówiąc:

W niektórych systemach na via 686a jest błąd sprzętowy; RTC automagicznie zmienia swoją zaprogramowaną wartość.

Łata została oryginalnie stworzona dla 2.4.2, a pewna jej wersja może być nałożona na obecne jądra (nie mam waniliowego 2.4.17 by to sprawdzić). Zajrzyj do arch/i386/kernel/time.c i poszukaj wzmianki o 686a.

Wydaje się, że jest to używane, jeśli jądro nie zostanie skompilowane z CONFIG_X86_TSC, jeśli więc masz to zdefiniowane, to możesz nie zobaczyć zupełnie tego problemu...

Berend De Schouwer zgłosił co mu się dzieje z jądrem 2.4.18: "W trakcie startowania jądra 2.4.18, przed tym jak uruchomione zostanie /sbin/init, konsola tekstowa się wali i nie da się nic przeczytać. Na ekranie pojawiają się wielokolorowe poziome linie. Wciąż da się uruchomić serwer X i działa on normalnie. Da się zalogować po ssh." Podesłał Łatkę, a Steven Walter odpowiedział: "Aha, jeszcze jeden. Jesteś czwartą lub piątą osobą z tym problemem. Mam łatkę bardzo podobną do twojej. To co robi moja łata, to czyszczenie bitu 7., co było eksperymentalnie zrobione by wyłączyć Write Memory Queue. Do tej pory wydaje się, że dotyczy to tylko KM133 (KT133 w/onboard S3 Savage)." Dodał jednak: "Łata nie jest zaakceptowana dopóki nie otrzymamy wyjaśnienia od VIA (najwyraźniej głównym ludziom od jądra powiedziano, by czyścili bit 5.). Pracuję teraz nad tym. " Berend replied, "Powiedziano mi to samo. Czyszczenie 5. bitu jest wyraźnie potrzebne w celu uniknięcia padu IDE. Asus wymienia dwie płyty, jedną z KL133 i jedną z KL133A. Wygląda na to, że płyty główne używające KL133s są zepsute, za to KL133As działa."

Ta łata umożliwia procesowi lub wątkowi zmieniać priorytet dynamicznie, w zależności od ustawionych capabilities. W naszym przypadku, chcieliśmy użyć wątków w Linuksie. Aby mieć prawdziwe priorytety, potrzebujemy uprawnień roota, aby ustawić SCHED_FIFO lub SCHED_RR; w wielu przypadkach oddanie uprawnień roota jest niedopuszczalne, ale dalej chcielibyśmy móc ustalać priorytety. Zaczęliśmy zatem używać setpriority do ustalania priorytetu wątku. Teraz użyliśmy wartości nice od 19 do 0, które nie wymagają uprawnień roota. W niektórych przypadkach wątek potrzebuje podwyższyć swój poziom nice, co zakończy się porażką. Na stronach podręcznika systemowego do renice(8) zauważyłem informację, że taki błąd istnieje.

Zatem następująca łata rozwiązuje ten problem. Pozwala dowolnemu procesowi i wątkowi zwiększyć lub zmniejszyć wartość nice w zależności od ustawionych capabilities. Na przykład proces z ustawionym CAP_SYS_NICE może użyć wartości pomiędzy 19 a -20, podczas gdy zwykły użytkownik może użyć wartości pomiędzy 19 a 0. Ponieważ zero jest wartością domyślną, to zmuszając zwykłego użytkownika do użycia zera, nie będziemy mieli żadnych problemów z konfliktami z programami z wyższym priorytetem.

Chris Wright odparł: "hmm, wygląda na to, że nie zgadza się to z SUS v3. ,,Jedynie proces z odpowiednimi uprawnieniami może obniżyć swoją wartość nice.''" Odbyła się krótka dyskusja, aż w pewnym momencie Stephen rzekł: "To wszystko wygląda, jak gołąb tańczący dookoła faktu, że w Linuksie nie ma zaimplementowanego PTHREAD_SCOPE_PROCESS, które jest tym, czego potrzebuję. To dopasowałoby lepiej Linuksa do modelu Solarisa i BSD wątków POSIX. Sądzę, że nie byłby to POSIX, jeśli każdy zaimplementowałby ten sam zbiór obsługiwanych cech. I to jest powód, dla którego znalazłem sposób na zmianę wartości nice bez tych całych cyrków z superużytkownikiem / capabilities." Ale dodał, że przyjrzy się temu jeszcze raz i spróbuje znaleźć lepsze rozwiązanie. Bill Davidsen odpowiedział:

Najzwyczajniej w świecie zrobiłem ,,man 3 pthreads'' i capability są wymienione jako dostępne... Jeśli możesz problem sprowadzić do małego programu testowego, jak ja zrobiłem, uruchomię go na Linuksie i Solarisie i zobaczę to, co zobaczę.

Oczywiście Linux nic tu nie implementuje, możesz wybrać implementację biblioteki i nagłówków pthreads, stare wątki z MIT na poziomie użytkownika, tak zwany model ,,wątków Linuksa'' albo obecny model NGPT z bieżącego jądra i biblioteki IBM.

To ostatnie działa, przynajmniej przy pewnej definicji ,,działania'', ale wiem, że są pewne różnice.

Nie widzę powodu, dla którego uruchamiasz dwa wątki z różnymi priorytetami, podczas gdy samo uruchomienie jest wystarczającym narzutem, aby go zauważyć, ale nie mam Twojego programu, więc może potrzebujesz jednak czegoś nietypowego.

Eric Hokanson zgłosił błędy przy próbie kompilacji 2.2.21-rc2 przy użyciu gcc 2.96. Alan Cox odparł: "Nie używaj, proszę, gcc 2.96/gcc 3.0/3.1 do budowania jąder 2.2. W tych jądrach przyjęto pewne założenia, które nie są zgodne z nowymi kompilatorami." Koniec wątku.

Zebrano tu wszystko co zdarzyło się w 2.4 przez ostatnie kilka miesięcy, zawiera kawałki z tych tygodni z Linux-kernel i dorzuca różne poprawki związane z kompilacją, więc mam nadzieję, że się udało. Szczególnie warta uwagi jest jedna z poprawek Andre dotycząca ide, informacja zwrotna na ten temat jest mile widziana od wszystkich, którzy widzą problemy w głównym 2.5.

Wśród innych nowinek mogę wymienić początek dzielenia gigantycznego diffa na wiele drzew Bitkeepera. Mam nadzieję, że gdy Linus wróci, synchronizacja powinna być znacznie łatwiejsza niż do tej pory.

Jak zwykle... Łata dla waniliowego 2.5.7 jest dostępna pod adresem: ftp://ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/

Archiwum połączonych łat: http://www.codemonkey.org.uk/patches/merged/

Sprawdź http://www.codemonkey.org.uk/Linux-2.5.html przed zgłoszeniem znanych błędów, które znajdują się także w głównej linii.

2.5.7-dj2

Łączenie kawałków z 2.4.19pre3 & pre4. Upuściłem niektóre, 2.5 zaczyna się naprawdę mierzyć w niektórych obszarach.
Kilka poprawek przy kompilacji. (ja)
Kilka aktualizacji config.help. (Steven Cole, ESR)
Poprawka kompilacji AFFS. (Jarno Paananen)
Aktualizacja bttv, aby używało nowego API v4l. (Jarno Paananen)
Usunięcie namiarowych BUG() z kodu zliczającego. (Bob Miller)
Usunięcie wyścigu z tnxmgr w JFS. (Christoph Hellwig)
Aktualizacja spisu dokumentacji. (Rolf Eike Beer)
Użycie seq_file w /proc/partitions. (Radny Dunlap)
Poprawka mentalnej literówki kdev_same w initrd (Al Viro)
Mała aktualizacja sg. (Doug Gilbert)
instalacja .config przy 'make install' (Kelly French)
Dodanie następnego VAIO do czarnej listy DMI APM. (Michael Piotrowski)
Wykrywanie błędów get_block w block_read_full_page. (Anton Altaparmakov)
Wybicie noquot.c (Al Viro)
Specjalny przypadek przy inicjalizacji bluesmoke P4/Xeon. (Jon Hourd)
Poprawka literówki w dokumentacji ide-scsi. (Bill Jonas)
Zwiększanie licznika tcpPassiveOpens. (Dave Miller)
Uwzględnienie kilku uwag Linusa odnośnie SEM_UNDO (Dave Olien)
Poprawka kompilacji ibmphp. (Greg KH)
Poprawka dwóch potencjalnych awarii w sterowniku mikrokodu. (Tigran Aivazian)
Zgodność kodów powrotu fcntl z POSIX. (Christopher Yeoh)
Zmniejszenie komunikatów debugujących z ide-tape. (Alfredo Sanju?n)
Różne poprawki ide, pdc4030 lekko podrasowany przeze mnie, testujcie ostrożnie. (Andre Hedrick)
Obsługa storage USB EasyDisk. (Stanislav Karchebny)
Zapisywnie na dysk cache/TLB w MCE. (Me)
Usunięcie podwójnego zwalniania pamięci w obsłudze partycji efi. (Takanori Kawano)
Poprawka literówki w dokumentacji pci_set_mwi. (Geert Uytterhoeven)
Usunięcie wyścigu w sterowniku indydog. (Dave Hansen)
Aktualizacja sterownika 3ware. (Adam Radford)
Poprawka błędu mmap dla sterowników, które poprawiają vm_start. (Benjamin LaHaise)
Rejestracja gameportu mad16 w podsystemie wejścia. (Michael Haardt)
Usunięcie zbędnych komentarzy. (William Lee Irwin III)
Obsługa P4/Xeon Thermal LVT dla MCE. (Zwane Mwaikambo)
Różne poprawki kompilacji fbdev. (James Simmons)
Przeniesienie sterowników ekranów dotykowych do własnego katalogu. (James Simmons)
Oddzielenie reiserfs_sb_info od struktury super_block. (Brian Gerst)

Nathan Walp zgłosił pełen sukces przy tej wersji, ale zgłosił błędy kompilacji aic7xxx_osm.c przy kolejnej -- -dj2; Dave obiecał przyjrzeć się temu, a Bill Davidsen zauważył: "Nie mam jeszcze tej wersji (tak naprawdę, to jeszcze nawet nie próbuję 2.5), ale założę się, że coś złego stało się z nagłówkiem udostępniającym strtok." Dave odparł: "Rzeczywiście, ubiłem w moim drzewie wszystkie strtoki i zastąpiłem je całkiem prostym kawałkiem kodu wykorzystującym strsep. A to jest jeden z przypadków, gdzie to przeoczyłem i pewnie warto dodać to do mojego skryptu 'sprawdź diff przed wysłaniem'."

Adam D Scislowicz zgłosił, że na jego komputerach SMP z Athlonami, pierwszy z procesorów, gdy używał 2.4.18-rc4, zawsze pokazywał złą informację w /proc/cpuinfo. Nazwa modelu brzmiała ,,AMD Athlon (tm) MP 1800+'', a identyfikator modelu -- ,,AMD Athlon(tm) Processor''. Maarten Ballintijn zgłosił: "To samo dzieje się na naszych płytach głównych Tyan S2460 przy 2.4.19-pre4-ac2. IIRC to BIOS ustawia te napisy." A Dave Jones także obwinił BIOS mówiąc, że producenci nie dbają o zgodność ze specyfikacją. Powiedział: ",,AMD Athlon(tm) Processor'' jest wartością domyślną po włączeniu. Jeśli procesor jest XP albo MP (sprawdza się to odczytując bit MP wśród flag procesora), powinien ustawić napis z nazwą. Dziadowskie BIOS-y robią to tylko dla pierwszego procesora. To jest nieszkodliwe, ale postaram się kiedyś napisać jakąś poprawkę na to podczas uruchamiania systemu." Koniec wątku.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	15 mar 2002 - 23 mar 2002	(30 posts)	Status RFC 2385 w Linuksie
2.	21 mar 2002 - 25 mar 2002	(10 posts)	Maksymalna liczba wątków w systemie
3.	21 mar 2002 - 22 mar 2002	(3 posts)	Maksymalny rozmiar partycji
4.	22 Mar 2002 - 26 Mar 2002	(22 posts)	Dyskusja na temat SSSCA
5.	23 mar 2002	(2 posts)	Status ftape w 2.4
6.	24 mar 2002 - 25 mar 2002	(9 posts)	Nowy sterownik NTFS
7.	26 mar 2002 - 27 mar 2002	(6 posts)	Status opieki nad ATM
8.	27 mar 2002 - 28 mar 2002	(13 posts)	Porównanie systemów plików
9.	27 Mar 2002	(6 posts)	Błędne czasy systemowe w ostatnich jądrach 2.4 na niektórym sprzęcie
10.	27 mar 2002 - 28 mar 2002	(4 posts)	Konsola się wali na niektórych płytach głównych z 2.4.18
11.	27 mar 2002 - 28 mar 2002	(7 posts)	Zmiana priorytetu procesu przy pomocy capabilities
12.	27 mar 2002	(2 posts)	Używanie nowych kompilatorów do jąder 2.2
13.	27 mar 2002 - 28 mar 2002	(8 posts)	Przenoszenie kodu z 2.4 do 2.5 w jądrach -dj; Przejście na BitKeepera
14.	28 mar 2002	(3 posts)	Niektóre BIOS-y mają problemy z ustawieniami /proc/cpuinfo

Kernel Traffic #160 For 2002/04/01

By Zack Brown

Translated By: Maja Królikowska and Paweł Kot