tux

Tak samo dobrze :)

U mnie w ustawieniach sieci pokazuje wszystkie dane.

Tak więc na pytanie sam sobie odpowiedziałeś :) Zachodzę tylko w głowę po co było do tego potrzebne forum? :D

Jak z tunera ktoś nie robi choinki to wystarcza z przechodem NOR - tutaj ta pamięć jest dość szybka.

Ja do sprawdzenia adresu IP uzywam PPanel. Jednak z ciekawości zapytam - gdzie szukałeś tego IP?

Zacznijmy od tego, że paczki z kernelem są do ręcznej a nie automatycznej instalcji. Jeżeli próbujesz instalowac kernel w Graterlia przy pomocy automatów to raczej od razu daruj sobie JFS. Wsparie JFS jest póki co ZEROWE i nie zanosi się na zmianę tego faktu.

1. Użyłeś kernela z obsługą JFS? 2. Skąd masz takie informacje? Podaj jakieś źródło tych informacji.

NOR jest na tyle szybki, że różnicy w prędkości nie ma w stoaunku do USB jak to ma miejsce w ADB. Przy zachowaniu rozsądku to i w NOR będzie dużo wolnego.

mkfs.ext2 -L "records" -O dir_index /dev/sdxy

JFSa nie będę wprowadzał do IMAGE jako standard bowiem nie uważam tego za konieczne. Za to na 100% dopiszemy system kontroli czy system był poprawnie zamknięty czy nie i jeżeli nie to odpal test dysku i naprawiaj. Oczywiście będzie info na wyświetlaczu.

ena w graniczach 299zł → dużo?/mało? jakość i poziom sygnału taki sam jak zwykłego konwertera można to rozgałęziać w dowolnym miejscu i dalej tylko jeden kabel do domu obsługa tylko jednego satelity - diseqC nie działa na to upewnij się, że tuner ma obsługe Uniable - BSKA/BSLA na 100% nie zadziała z Unicable!

Z inverto Ultra Black to bym uważał. Doczytać jakie ma wzmocnienie i pomyśleć na jakich długościach kabla należy to stosować! żeby potem nie płakać. Poprawiony błąd (pominięta pierwsza samogłoska w wyrazie "jakich").

Osobiście ze wszystkich co testowałem → SHARP

Kolega @richter prosił wiele razy. Ja tu też prosiłem. Ludzie jednak...nawet komentwać nie będę.

Ad 1 → może kiedyś Ad 2 → TAK Ad 3 → Tak ale nie wiem po co? Dla lepszego samopoczucia? Ad 4 → orogamowo 1:1 z ADB - oba to SH4

Z PPanels od 07.07.2013 dostępne są jedynie 1x1 orez 1x2. Po inne listy zapraszam na PW do kolegi @richter.

Zacznę od tego, że dla mnie temat jest już wyczerpany. Po latach używania róznych wersji systemów operacyjnych jak i róznych systemów plików liczy się dla mnie pewność i stabilność a nie to co najszybsze bo... To teraz od początku. @mickey miał problem z dyskiem i przy próbie napray zabrakło pamięci. Owszem - mogło jej zabraknąć - partycja jest przecież dużą partycją a nBox ma mało RAMu. Sam błąd wskazuje jednak na dwie sprawy: system plików u @mickey musiał przeżyć nie jeden szok :) i to nie mały - dlaczego? teraz pewnie tego nie wydumamy - u mnie sformatowane 250GB w nBox od listopada i ani jednego błędu na HDD a sprawdzam go co jakiś czas - jednak padów zasialania niekontrolowanych nie mam - sprzęt na UPSie; mamy potwierdzenie, iż mimo awarii systemu plików ext3/ext4 system działa dalaj - pomija uszkodzone fragmenty systemu plików - oczywiście po naprawie systemu plików uwolnione wolne miejsce zostanie odzyskane. Punkt numer 2 jest technicznie nie możliwy do wykonania dla ext2/reiserfs/JFS/XFS. Tu po awarii konieczna jest naprawa systemu plików. W przypadku XFS brak naprawy i wymuszenie działania dalej może doprowadzć do kompletnej zagłady systemu plików. @s6s - szanuję Twoje wypowiedzi. Jednak obawiam się, że gdzieś po drodze zatraciłeś "zdrowy rozsądek". Jak czytam tu na na forum to czerpiesz wiedzę przede wszystkim z internetu i opierasz się na jednostkowych, swoich przykładach. Widzisz jedną stronę medalu - nie dostrzegasz drugiej, albo nie chcesz jej dostrzegać. Aby zakończć (przynajmniej dla mnie) definitywnie temat napiszę to :) co poniżej. @s6s → nie zadałeś sobie trudu doczytania co tak naprawdę robi dziennik w JFS i jak on działa. Wyciągasz wnioski z jakiś jednostkowych wypowiedzi przecztanych w internecie, który nie jest najlepszym źródłem wiedzy w każdm przypadku, a już na pewno nie każde miejsce w internecie. Gdybyś doczytał uważnie na temat JFS - masz 300GB danych. Pada zasilanie i spójność systemu pada podczas zpisu. fsck.jfs podczas testu musi sprawdzić spójność każdego pliku oznaczonego jako potencjalnie uszkodzony. Problem zaczyna się wtedy gdy pliki mają po kilka giga a oznaczonch jest kilka. Dodatkowym problemem jest to co się dzieje jak system nie wstanie. Ale o tym później Coś takiego o czym piszesz to możesz wykonać (w zasadzie spróbować wykonać) na systemie plików ext3/ext4. W przypadku systemów plików, które po awarii w conajmniej 50% przypadkaów potrzebują ingerencji użytkownika to raczej nie jest dobry pomysł. Kolejny bardzo dobry pomysł ale nie przemyślany. wykonuje fsck w tle - na 100% pilot zacznie mieć problemy z reakcją, przełączanie kanałów zwolni - zwykły użytkownik pierwsze co zrobi to wyjmie wtyczke z gniazdka bo coś się dzieje - prawdopodobieństwo, że przeczyta chociaż plik readme z tymi informacjami o skanowaniu w tle jest zerowe skoro regulaminu forum nie czytało z 90% użytkowników nie pisząc już o FAQ czy historii wersji; jak zmniejsze zapotrzebowanie na zużycie procesora (nice) to skanowanie może się wykonywać nawet pół dnia - przeciętna osoba znowu zacznie szukać co nie tak i problem opisany w pkt 1 powróci. To Twoja skromna opinia i proszę ją zachować dla siebie. Po tym tekście widać badzo dokładnie, iż jeszcze ani razu nie odpowiadałeś za utratę danych ani nie musiałeś się z tego tłumaczyć jak również nie straciłeś nic co jest cenne dla Ciebie. Eksperymenty zostaw dla siebie a nie dla innych. Jak ktoś będzie chciał dołączyć do Ciebie - to jak napisał @pppp i ja wcześniej - macie na forum jądro z innymi systemami plików - testujcie. Wolna wola. Sprawdzałęś w praktyce na systemie plików po wilelu padach napięcia i z dużą ilością GB? Czy jedynie znowu opierasz się na internecie i suchych danych? Gubisz się kolego - tu nie chodzi o zarządznie dużymi plikami. Tu chodzi o czas dostępu do tych plików. My nie kopiujemy namiętnie plików po 2-6GB z miejsca na miejsce. My nagrywamy coś i to małymi partiami danch i odczytujemy też małymi partiamy danych. To czy system jest szybszy z dużymi plikami czy małymi dla nas nie ma znaczenia. Za to każde kronikowanie ograniczy czas dostępu do plików i to znacznie! Dlatego ext2 wygrywa nawet z JFS :) Na to odpowiedziałem wyżej :) Teraz coś na koniec tej odpowiedzi. Ja rozumiem (sam często też robie podobnie), że próbujecie traktować nBoxa jako komputer. Nawet to w sumie dobrze bo nie dość, że nim jest to nie jedna osoba nauczy się czegoś więcej niż klikania w Windows. Czasem jednak człowiek się zagalopuje w tym wszystkim. Zapomina, że ten komputer to w sumie służy do oglądania telewizji. O ile robimy to wszystko pod siebie, mamy wiedzę by coś pogrzebać jak padnie to OK. Najwyżej będziemy wściekli, że właśnie zamiast obejrzeć film na który czekaliśm miesiąc czy mecz na który czekaliśmy pół roku naprawiamy system plików w nBox. Wyobraźcie sobie (w szczególności @s6s), że coś się dzieje i nagle nBoxy nie wstają bo czekają na naprawę systeów plików. O 20 mecz Polska - ktoś tam i setki maili na skrzynce jaki to gówniany ten IMAGE Gaterlia bo zamiast oglądać mecz to oglądam napis nBox na wyświetlaczu. Eksperymenty możesz robicz i dyskutować o nich. Problem w tym, że ja i nie tylko ja odpowiedzieliśmy Ci już aż nadto dlaczego ext3/ext4 a nie JFS. Dlaczego ext2 a nie JFS. I dlaczego zalecany jest ext3/ext4. Nie można też zapomnieć o tym, że poważniej uszkodzony system plików JFS jak również uszkodzony ext2 wymaga interwencju użytkownika ZAWSZE!. Jak to wytłumaczysz tym, co mają problem z edycją byle pliku na nBox? O pewnch sprawach fajnie się rozmawia z punktu widzenia siebie bo to nie m potem odpowiadamy za skutki użycia danego np. pomysłu. Od tego momentu temat dla mnie jest zamknięty!

@s6s → A ile danych miałeś na tej 0,5TB partycji? Było tam chociaż 300GB? I coś jeszcze. Wiesz jak naprawić - odpaliłeś - działa. Teraz stań tu na forum i ucz ludzi,jak to robić, jak zacznie padać na potęgę. Widzisz → tu już nie chodzi o JFS vs ext2. Tu chodzi o wygodę. Przy ext3/ext4 mało jest przypadków naprawy ręcznej!

Dziennik dla JFS fikcją nie jest. Problem w tym, że przy zastosowaniu JFS tutaj w nBoxie nie ma on najmniejszego znaczenia. Co innego na serwerze plików, czy komputerze typu desktop. Tam będzie wydajniejszy od ext2 ze względu na rodzaj danych magazynowanych na tych nośnikach. W nBox liczy się dostęp do relatywnie małej ilości danych. Toteż czy dziennik jest (JFS), czy go nie ma (ext2) różnicy nie będzie. Co innego ext3 i ext4, gdzie kronikowane są wszystkie operacje na dysku. Tu mamy przynajmniej zestaw danych naprawczych pomocnych przy skanowaniu dysku. Polecenie fsck nie mieli całych partycji, a jedynie te fragmenty, które nie są spójne. Jak pisałem wcześniej, powoduje to znaczny spadek prędkosci zapisu, jak również obciążenie cpu. Jak to się pisze - coś za coś. JFS nie ma standardowo w kernelu, ext2 jest. Skoro i tak po awarii czeka mnie fsck, to użycie JFS moim zdaniem mija się z celem. Poprawione błędy wynikające z pisania z klawiatury aparatu komórkowego.

Ja nie używam w ogóle PTS to się nie wypowiem. Ale jak pisałem wcześniej → dałem wszelkie wariacje kernela i każdy wybierze co chce.

Zacznę od końa. JFS2 póki co nie mam dla SH4. Może coś wymyślę. Co do awarii po padzie zasilania. ex2fs przeskanujesz fsck i już - będzie OK. JFS tak samo. Problem w tym, że to trwa. Zakładając, że nie ma DMA i jest 250GB do skanowania to kilka do kilkunastu minut. Przeciętny user nBoxa "jajo zniesie". Dzienniki w ext3fs i ext4fs skracają tej czas do takiego minimum, że można praktycznie to pominąć. To jest ta różnica. Jednak jest to opatrzone większym zapotrzebowaniem na CPU podczas normalnej pracy. Dlatego rozważając, że JFS ma dziennik... Jak ktoś ma lepsze samopoczucie własne, że ma dziennik i on coś mu to pomoże to OK. Niech dalej tak myśli. Co do osobnej partycji na PTS. Pewnie, że da się. Ptanie jednakże jak szybko "zajeździmy" ten fragment tależa dysku? Przecież non-stop będzie "rzeźbiony" ten sam fragment.

Ten "mod" to oznaznie, że systemy plików sa jako moduły do ręcznego załadowania.

Problemem nie jest to narzędzie. Problemem jest to, że jak ręcznie nie napramimy to możemy doprowadzić do "zagałady" systemu plików. Jak dodamy do fstab zamiast 0 0 wpis 1 1 to owszem - system sam zacznie naprawiać błędy. Tu jednak kolejny problem. Jak czegoś nie będzie mógł skorygować każe zalogować się na root-a i naprawiać ręcznie. Tego na ekranie TV nie pokaże a jedynie w terminalu podpiętym do DEBUG. W przypadku ext3fs i ext4fs jak coś się stanie to naprawde w extremalnym przypadku poprosi o logowanie na root-a. Ty zapewne dasz sobie radę. jakaś mała część użytkowników też. Jednak zdecydowana większość niestety NIE. Skończy się to pisaniem elaboratów na forum, żaleniem się i...i innymi takimi tam. Dlatego załączyłem różne kernele do wyboru i nawet narzędzia dla XFS i RaiserFS. Każdy wybierze coś dla siebie. EDIT Może i maił mniej do roboty. Ale w teście to nie ma znaczenia bowiem każdy z testów wykonany był tak samo. Jeżeli włączę dowolny kanał to od tego co będzie w danej chwili nadawane będzie zależeć wynik. Tu i tak obciążenie procesora jest 100% w każdym przypadku. Co do zjadania CPU. ext2fs vs JFS → dla mnie wygrwa ext2fs. Dlaczego? Obciążenie podobne przy praku dziennika. Dziennik w JFS przydatny w zastosowaniu nBoxa jak piąte koło u wozu. Dlaczego? Bo służy do szybszego wyszukiwania plików. Jakbyśmy mieli do czynienia z milionami plików na HDD to może i owszem. Dla stabilności na awarię nie ma znaczenia dziennik w JFS. Po awarii i tak trzeba odpalić fsck.jfs. Skoro muszę odpalić fsck to dla mnie nie ma różnicy czy odpalę to dla jfs czy ext2fs. Najwięcej procesora zjada własnie dziennikowanie:) Wszystkie partycje to jedna partycja 250GB na dysku formatowana opcjami standardowymi.

Piszę w osobnym poście bo...sami zobaczycie bo.... :) Zabrałem się dzisiaj za test systemów plików na nBox. Zgodnie z moimi oczekiwaniami wygrał ext2fs. Drugi był JFS. Pamiętać należy, że jedynie ext3fs/ext4fs sa w dużym stopniu odporne na awarie. Niestety kosztem wydajności. Jeżli nie przeraża nas ewentulalne napraniwanie systemu plików z konsoli to ext2fs jest najlepszym wyborem. Ale każdy może mieć swoje zdanie. Poniżej wyniki testu. Test przeprowadzony na BSKA z odłączoną anteną sat i dyskiem 250GB Seagate. Antena Sat odłączona celowo ze względu na stabilność parametrów - chodziło o miarodajne wyniki. W załączniku różne warianty kernela dla ADB5800xx. Dla ext4: tuxish-Box:/hdd# /root/test.sh dd if=/dev/zero of=swapfile bs=1024 count=524288 524288+0 records in 524288+0 records out 536870912 bytes (512.0MB) copied, 87.427903 seconds, 5.9MB/s dd if=swapfile of=/dev/zero 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 26.485291 seconds, 19.3MB/s dd if=swapfile of=swapfile2 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 178.324211 seconds, 2.9MB/s tuxish-Box:/hdd# Dla ext3: tuxish-Box:/hdd# /root/test.sh dd if=/dev/zero of=swapfile bs=1024 count=524288 524288+0 records in 524288+0 records out 536870912 bytes (512.0MB) copied, 95.716709 seconds, 5.3MB/s dd if=swapfile of=/dev/zero 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 26.369835 seconds, 19.4MB/s dd if=swapfile of=swapfile2 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 182.685310 seconds, 2.8MB/s tuxish-Box:/hdd# Dla ext2 tuxish-Box:/hdd# /root/test.sh dd if=/dev/zero of=swapfile bs=1024 count=524288 524288+0 records in 524288+0 records out 536870912 bytes (512.0MB) copied, 51.514865 seconds, 9.9MB/s dd if=swapfile of=/dev/zero 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 26.238987 seconds, 19.5MB/s dd if=swapfile of=swapfile2 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 104.329448 seconds, 4.9MB/s tuxish-Box:/hdd# Dla JFS: tuxish-Box:/hdd# /root/test.sh dd if=/dev/zero of=swapfile bs=1024 count=524288 524288+0 records in 524288+0 records out 536870912 bytes (512.0MB) copied, 61.583602 seconds, 8.3MB/s dd if=swapfile of=/dev/zero 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 38.716802 seconds, 13.2MB/s dd if=swapfile of=swapfile2 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 123.289417 seconds, 4.2MB/s tuxish-Box:/hdd# Dla ReiserFS: tuxish-Box:/hdd# /root/test.sh dd if=/dev/zero of=swapfile bs=1024 count=524288 524288+0 records in 524288+0 records out 536870912 bytes (512.0MB) copied, 162.928757 seconds, 3.1MB/s dd if=swapfile of=/dev/zero 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 42.015135 seconds, 12.2MB/s dd if=swapfile of=swapfile2 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 312.190383 seconds, 1.6MB/s tuxish-Box:/hdd# Dla XFS: tuxish-Box:/hdd# /root/test.sh dd if=/dev/zero of=swapfile bs=1024 count=524288 524288+0 records in 524288+0 records out 536870912 bytes (512.0MB) copied, 66.967753 seconds, 7.6MB/s dd if=swapfile of=/dev/zero 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 41.721146 seconds, 12.3MB/s dd if=swapfile of=swapfile2 1048576+0 records in 1048576+0 records out 536870912 bytes (512.0MB) copied, 148.357925 seconds, 3.5MB/s tuxish-Box:/hdd# kernel-Graterlia_v1.0.0.tar.gz reiserfs.tar.gz xfsprogs.tar.gz

Fragmentacja przy dużych plikach problemem nie jest. Gorzej z awaryjnością. Edit: Poprawione błędy wynikające z użycia innej klawiatury (mylenie klawisza "r" z "e", które znajduje się obok).