równoleglenie sysfscheck i openpli dla przyspieszenia boot-owania

[Gość s6s]

Jak można zauważyć skrypt openpli uruchamia sie równolegle względem ewentualnych innych skryptów z danego runlevel-a które występują po nim jako linki w  /etc/rc.d/rc5.d/S<numer><nazwa>

 

Więc taki drobny pomysł przyspieszający ładowanie sie systemu...

 

Otóż może by rozbić zawartość /etc/init.d/gsysfscheck na osobne pliki:

pierwszy to sprawdzjący sam ROOTFS i uruchamiany na początku jak dotychczas,

ale skrypt sprawdzający nośniki zewnętrzne (a więc głównie /hdd ) postawić jako link w kolejności za /etc/rc.d/rc5.d/S89openpli

 

Wówczas sprawdzanie systemu plików na dysku twardym (jak wystąpią błędy to możliwe że długotrwałe) wykonuje sie równolegle ze startem samej Enigmy (równiez długotrwałym).

Ponieważ sprawdzanie/reperowanie systemu plików Ext2/Ext3/Ext4 pomimo że długotrwałe to nie angażuje specjalnie CPU więc w ten sposób mielibyśmy przyspieszenie gotowości naszego tunera do oglądania programów (po włączeniu po zaniku napięcia czy cuś)

 

Jak sprawdzam u siebie to mi to działa, ale potrzeba przywiązać uwagę aby zmienić opcje montowania w /etc/fstab na "noauto" dla "records" i "data" i montować w właśnie tym osobnym skrypcie (po wykonaniu fsck) za pomocą polecenia "mount LABEL=cośtam"

 

Trochę to kłopotliwe i niespójne bo jeżeli np. wyłączymy sprawdzanie fs (albo wyrzucimy link do tego slryptu z rc5) wówczas tuner zabbotuje bez podmontowania records i data. Więc przydałoby się jakieś sprawdzenie potem (może w crontab?)

 

Oczywiście mozna również w tym skrypcie odmontować partycje przed sprawdzaniem, lub remontować jako "readonly"...

Jak lepiej? (Ponieważ odmontowanie/remontowanie chyba troszkę może potrwać szczególnie w razie kłopotów?) 

 

W każdym razie chyba się to opłaca ponieważ warto podkreślić ponownie: (od/re)montowanie czy samo sprawdzanie systemu plików nie obciąża procesora niemal wcale więc może system sobie robić je w tle...

 

...że nie wspomnę że może sobie je robić np. podczas kiedy tuner sobie śpi - za pomocą crontab - wówczas przydałoby się jakoś odczytać czy Timer-y nie mają zaplanowane nagrywanie audycji w niedalekiej przyszłości itp.

Jak odczytać wartości w Timer-ach?

 

[mickey]

Jak odczytać wartości w Timer-ach?

 

http://forum.xunil.pl/index.php?topic=449.msg5618#msg5618

 

A reszta ... przeczytaj to jeszcze kilka razy i zastanów się, czy to na pewno ma sens. W przypadku data można jeszcze sprawdzanie i montowanie przesunąć na później, ale records raczej powinien być czysty i dostępny kiedy enigma2 wstaje. Sam napisałeś "Trochę to kłopotliwe i niespójne (...)". Gdyby jeszcze modyfikować źródła openpli, żeby w razie braku /hdd proces uruchamiania się zatrzymał do czasu jego podłączenia ... tylko po co? Więcej z tym kłopotu niż pożytku.

 

A tak ogólnie, to jaki sens ma sprawdzanie dysku co jakiś czas z crona? Na starcie jest to robione, bo zdarza się, że tuner nie jest poprawnie zamykany i warto sprawdzić system plików. Ale jak już wstał i działa i narobił większego bałaganu nagrywając na uszkodzoną partycję, to po co? W czasie normalnej pracy systemy plików nie mają w zwyczaju się uszkadzać.

 

[Gość s6s]

Owszem, już widzę inny konflikt, otóż jak Enigma wstaje to prawdopdobnie automount montuje "data" żeby E2 mogła odwołać się do /media/data/epg.dat  oraz picons

i niestety robi to podczas kiedy moja "usługa" przeprowadza właśnie fsck

W efekcie mam rozwalony filesystem na data ;)

 

Więc ze względu na "data" ciężko robić te rzeczy - ale co do "records" nie widze na razie konfliktów...

Pewnie Ty masz na myśli że trzymasz epg.dat na hdd? (nie chcę epg.dat trzymać na hdd żeby dysk nie szalał co chwilę)

 

Ale jeżeli by trzymać całość kompletnych danych na "data" (na penie)

a na "records" wyłącznie multimedia - wówczas może miałoby sens

aby sprawdzać "records" równolegle ze startem Enigmy? 

 

W ogóle to przyznam nie wiem ile czasu trwałoby sprawdzanie solidnie "zabrudzonego" systemu plików ext4, ext2 czy też jfs - jak dotąd miewam tylko drobne incydenty i naprawa trwa zwykle parę sekund...

Jeżeli natomiast realnym wydwałoby się zagrożenie że sprawdzanie potrwa wydatnie dłużej wówczas moznaby się pokusić aby tak pokombinować...

 

Przy okazji z tymi timer-ami aby wykyć czy cron może np. zrestartować system... Otóż jeszcze możnaby spróbować (w skrypcie) odmontować "records" i jak mount odmówi to znaczy że coś lub ktoś tego używa więc trzeba poczekać wówczas z restartem...

 

 

 

 

[Gość j00zek]

Takie zmiany spowodują zaoszczędzenie tylko paru sekund w przypadku uporzadkowanego systemu.  Także korzyści są niewspółmiernie do komplikacji. Najwięcej czasu zajmuje startowanie samego kernela i openpli i tutaj można jedynie wyświetlić live tv podczas uruchamiania. Ten zabieg "przyspiesza" blokowanie o jakieś 30 sekund.

[mickey]

(...) ale co do "records" nie widze na razie konfliktów... (...)

 

(...) a na "records" wyłącznie multimedia - wówczas może miałoby sens (...)

 

Kiedy właściwie padnie Ci system plików?

1. Jak zakład energetyczny wyłączy prąd, czyli zwykle i tak przeglądasz oglądanie, więc wszystko jedno jak długo się to sprawdza.

2. W czasie kiedy akurat coś się nagrywa z timera albo coś oglądasz z dysku albo jedno i drugie i ... nawet jeżeli się nie zawiesi, to nie wytrzymasz nerwowo i wyciągniesz wtyczkę z gniazdka.

3. Wymuszony restart przy testach czegoś nowego ... ale to nie jest operacja, która przystaje do normalnego użytkowania.

 

W tym drugim przypadku. W moim odczuciu (aczkolwiek z zaznaczeniem: kiedyś) najczęstszym najważniejsze wydaje się sprawdzenie records...

 

W ogóle to przyznam nie wiem ile czasu trwałoby sprawdzanie solidnie "zabrudzonego" systemu plików ext4, ext2 czy też jfs (...)

 

Jeżeli potrzebujesz dokładnie to pomęcz google albo jakiś dysk, ale z tego co przeczytałem, chociażby na tym forum: W przypadku systemów plików z dziennikiem (ext4, jfs) jest to chwila w przypadku systemów plików bez dziennika (ext2) ... długo. Liczy się w długich minutach nawet na niedużym dysku. Zdaje się ok. 20 min. na dysk 250G.

[tux]

@s6s → czy ty uważasz, że wszyscy Twórcy Systemów Operacyjnych mylą się?

Każdy Linux sprawdza FS przed wystartowaniem. Nawet MS to robi w przypadku Windows od 95 w górę.

 

Jesteś "grzebaczem" i nawet się do tego przyznałeś tu na forum.

Pomyśl tak. Masz samochód. Wsiadasz do samochodu i odpalasz go od razu niezależnie od wszystkiego i ewentualnie sprawdzasz co jest nie tak jak już jedziesz? Jeżeli tak to możesz nie zauważyć przeciętej opony i rozwalić sobie felgę, może oś albo i coś więcej. Może nawet wjedziesz w drzewo.

To samo jest z FS i OS. Nie wyobrażam sobie jakiegokolwiek działania OS na niesprawnym systemie plików. Konsekwencje będą tak dalece nieprzewidywalne, że nawet myśleć nie chcę.

 

Czasem, @s6s, zdajesz się nie podchodzić do zagadnienia logicznie. Pomyśl nad tym.

 

[Gość s6s]

Przepraszam Tux ale nie rozumiem, przecież difoltowo każdą linijkę wpisów w fstab zamykają same zera...

Osobiście nie śmiem przedstwiać się tutaj jako osoba co wie tyle co Wy, Szanowni Koledzy, lecz pokornie pragnę zauwayżyć że zrównoleglenie startu (i zamykania) ma już niemal każda dystrybucja Linuksa na PC: obowiązkowo z systemd jak i również opcjonalnie (można sobie zadać w konfiguracji) z OpenRC...

 

chwila w przypadku systemów plików bez dziennika (ext2) ... długo. Liczy się w długich minutach nawet na niedużym dysku. Zdaje się ok. 20 min. na dysk 250G.

Aha, czyli jednak WARTO  w przypadku "records" z ext2 na tunerze ze słabym CPU np. ADB5800 (jak już wcześniej wyjaśniliśmy to sobie tutaj kiedyś... ;))

 

Najwięcej czasu zajmuje startowanie samego kernela i openpli i tutaj można jedynie wyświetlić live tv podczas uruchamiania. Ten zabieg "przyspiesza" blokowanie o jakieś 30 sekund

Więc MOŻNA wyświetlić audycję lecącą na bieżąco z głowicy jeszcze przed PEŁNYM wystartowaniem Enigmy? Jak? Ponieważ jeżeli tak chyba gra warta świeczki, czyż nie? ;)

 

P.S. Jeszcze tak troszke kombinując... czyz nie dałoby się jakoś zablokować montowania danej partycji przez coś innego podczas kiedy fsck ją sprawdza? Wówczas czy proces /etc/init.d/openli poczekałby (z odwoływaniem się do epg.dat i picons) aż blokada zwolniłaby się? Czy też po prostu Enigma wystartowałaby bez tych plików na "data" oraz stworzyłaby nowe epg.dat w pustym katalogu /media/data do którego moja"usługa" sprawdzania po przeprowadzeniu fsck i tak zamontowałaby partycję "data" - więc znów bałagan...

 

 

 

[Gość j00zek]

do skasowania

[tux]

@s6s → przypomnij sobie dlaczego powstał skrypt od sprawdzania systemów plików!

[Gość s6s]

@j00zek, to SUPEEER! Jednak pół minuty to sporo! :) Wówczas nie wiem czy by nie opłaciło się częściej wyłączać tuner w ogóle!

(Jeszcze do pełni szczęścia brakowałoby sterownika dającego wyłaczanie tunera softwareowo poprzez "halt" - ale nawet i bez tego dawałoby super efekt!)

 

@Tux, jasne, popraw mnie jeżeli coś przeinaczam ale cała sprawa zaczęła się od słabego CPU w ADB5800 - za słabego do obsługi ext4, więc wyraźną ulgę przyniosło postawienie "records" na ext2 (lub jfs) - ale to z kolei wymagało częstego sprawdzania systemu plików, przy każdym starcie w zasadzie.

Jednak Ty (oraz inni autorzy?) niejako przy okazji wprowadzili także sprawdzanie ROOT-FS oraz innych montowanych przy starcie nośników/partycji - czyli w jak narazie zasadzie tylko "data" jeszcze...

 

Więc sugerujesz żeby sprawdzać na samym początku ROOT-fs i "data" (na penie gdzie znajdą się epg.dat i picons) a "records" (z samymi multimediami) równolegle podczas zapuszczania Enigmy (/etc/init.d/openpli)?

 

OK, w sumie ma to sens - jednak jak @Mickey zauważył warto się w to "bawić" jedynie dla "records" na ext2

 

Jednak jak tutaj oświecił nas j00zek PRZEDE WSZYSTKIM fajnie zrobić to równoległe puszczanie audycji z głowicy podczas startowania samej Enigmy!

@j00zek - ale co rozumiesz przez "Hybryda"?

 

[tux]

Soft na tuner jest tak mały i okrojony, że standardowe ustawianie z 0 na 1 w fstab nie zadziała. Ta funkcja nie jest zaimplementowana. Dlatego powstał skrypt sprawdzający. Być może kiedyś stanie się częścią "mountall".

 

Co do włącz/wyłącz. Cóż - to jest Graterlia OS. Z założenia ma działać a restart tylko jak już naprawdę trzeba.

[Gość s6s]

Wiesz, w sytuacji kiedy nie ma "głebokiego standby" wielu posiadaczy tunera np. ESI przywitałoby z radością szybki boot i chętnie często wyłączałoby tuner w ogóle kiedy nie planują żadnego nagrywania - wszak zżera niepotrzebnie amperogodziny ;)

 

Jedynie tylko jakoś podpiąć pod pilota szybkie zamknięcie systemu, np. wykorzystując irexec ?

(patrz: http://forum.xunil.pl/index.php?topic=1128.msg13399#msg13399 )

 

[tux]

Realnie to ile zaoszczędzisz?

Poszaleliście z tymi oszczędnościami. W skali roku to kropla i tylko kropla. Ale skoro jest tak wielkie lobby EKO to co poradzić.

 

Dla mnie tuner z GraterliaOS to komputer. Można go uśpić (standby) i tyle.

 

[AbrahaM]

Wiesz, w sytuacji kiedy nie ma "głebokiego standby" wielu posiadaczy tunera np. ESI przywitałoby z radością szybki boot i chętnie często wyłączałoby tuner w ogóle kiedy nie planują żadnego nagrywania - wszak zżera niepotrzebnie amperogodziny ;)

 

Żartujesz? napisz proszę że żartujesz...

 

Jeśli nie żartujesz, to zmierz sobie (znam wyniki, ale wolę byś przekonał się samodzielnie, naocznie) pobór prądu podczas pracy i w standby przez poszczególne odbiorniki. Ze szczególnym naciskiem na polecane przez nas Sagecomy. Po czym zastanów się nad sensownością tego, co napisałeś powyżej.

 

Przy okazji przypomnę, że elektronice (zazwyczaj, poza wyjątkami rażąco źle zaprojektowanego sprzętu), bardziej szkodzi cykl włącz-wyłącz niż praca ciągła.

[Gość s6s]

OK, ale w takim razie fajnie jakby obraz z głowicy można ciągle wyświetlać np. podczas restartu samej Enigmy - bo chyba da się to zrobić jak wynika z tego co napisał wcześniej tu j00zek...

 

[tux]

Dać się da. Tylko w założeniu GOS nie ma tego póki co. Dlaczego? Bo założenie jest takie, że uruchamiasz i działa a nie robisz dziesiątki restartów dziennie.

[Gość s6s]

Ale GreenScreen-y się zdarzają, wtedy ktoś może oglądać coś ważnego i zaklnie jak mu obraz zniknie na ponad minutę...

Poza tym to takie psychologicznie... fajne! :)

 

(Poza tym przecież inaczej nie da się zapisać ustawień Enigmy w tym zmian listy kanałów niż poprzez jej restart)

 

---

 

A jeszcze a propos równoległego sprawdzania "records" zobacz co pisaliście w sąsiednim wątku o tym jak ktos włącza tuner i... czeka godzinę patrząc na napis    "    Rec FS  Test  "  na wyswietlaczu:

Zależy jaki system plików ale przy dużej ilości błędów ze 2-3h na pewno.

Jeżeli będzie coś nie tak to wyświetli Ci:

Root FS notOK

Widzisz jednak przydałoby się pomysleć nad tym aby fsck sprawdzał partycję "records" w tle (wyzwolony np. przez przez crontab) i wówczas kiedy nic albo nikt nie używa tej partycji...

 

Właściwie zapisanie tego w crontab to nie duży kłopot, włącznie ze sprawdzeniem czy Timers nie planują nagrywania i czy tuner właśnie "nie chodzi".

Jakby jeszcze wybrać taką opcję żeby sobie w tle to leciało także podczas oglądania (a nie tylko podczas standby) - to wówczas trzeba by zaimplementować funkcję natychmiastowego przerwania fsck i od razu zamontowania "records" (kiedy widz sobie włączy "instant record" albo TimeShift). Czy da się to tak zrobić? Ponieważ z tej całej sprawy tylko tego nie wiem...

 

A! Jeszcze czy da się zrobić "mount -o remount -r ..." (przemontować na readonly) dla sprawdzania przez fsck?

Wtedy widz mógłby sobie przynajmniej odtwarzać player-em nagrane wczesniej audycje tv podczas gdy fsck by robił swoje...

 

Widzą, że tak robi skrypt  /etc/init.d/gsysfscheck dla ROOTFS (remount-uje na readonly) i sprawdza. Ale jak chcę tak zrobić z "records" na ext4 to fsck nie chce wtedy się tego podjąć... :-/ Wiesz może dlaczego?

 

[tux]

Ale GreenScreen-y się zdarzają, wtedy ktoś może oglądać coś ważnego i zaklnie jak mu obraz zniknie na ponad minutę...

Poza tym to takie psychologicznie... fajne!

U mnie się zdarzają, ale jak sam je wywoła. Inaczej nie wiem, co to GS. Podczas normalnej pracy odbiornika polegającej na oglądaniu/nagrywaniu itp. nie wiem, co to GS.

Są jednak tacy, co widzą GSa nawet 100 razy dziennie - wystarczy grzebać ile wlezie w tunerze/opcjach/systemie i kombinować. Może warto wtedy mieć dwa odbiorniki? Jeden do oglądania i drugi do grzebania?

A może to ja jestem inny i nie wyobrażam sobie tego, że rodzina siedząc przy telewizorze nie "wydziera się w niebogłosy", że znowu coś nie działa.

Reasumując, tuner służący do oglądania ma dziesiątki dni uptime bez GSów itp. zdarzeń.

A jeszcze a propos równoległego sprawdzania "records" zobacz co pisaliście w sąsiednim wątku o tym jak ktos włącza tuner i... czeka godzinę patrząc na napis    "    Rec FS  Test  "  na wyswietlaczu:

Jeżeli ktoś "zapuści" dysk aż tak mocno z błędami, to co się dziwić? Najczęściej są to błędy nie z czasów Graterlia OS a innych wcześniej używanych softów lub innych używanych równolegle, gdzie kontroli nie ma. Jeżeli wszystko działa OK, to nie ma szansy na to, by oglądać czarny ekran godzinami.

zaimplementować funkcję natychmiastowego przerwania fsck

[glow=red,2,300]Czy ty w ogóle analizujesz to co piszesz? Chcesz doprowadzić dany system plików do kompletnej ruiny?[/glow]

Zabrzmi mocno, ale nie mogę powstrzymać tych myśli (użyję Caps Locka, albowiem chcę zaznaczyć): [shadow=red,left]NIEKTÓRZY NIE POWINNI NIGDY MIEĆ ŻADNYCH URZĄDZEŃ Z SYSTEMEM OPERACYJNYM, W KTÓRYM MOGĄ COŚ ZMIENIAĆ, PONIEWAŻ NIE SĄ W STANIE POJĄĆ ISTOTY DZIAŁANIA TYCH URZĄDZEŃ I NA SIŁĘ WYMYŚLAJĄ COŚ, CO NIE MA PRAWA DZIAŁAĆ LUB SPOWODUJE STRASZLIWE SKUTKI UBOCZNE. DLA NIEKTÓRYCH JEDYNYM SŁUSZNYM WYBOREM JEST (BIORĄC POD UWAGĘ SAT) ODBIORNIK DOSTAWCY USŁUGI GDZIE NIE MOŻNA GRZEBAĆ ALE ZA TO DZIAŁA.[/shadow]

A! Jeszcze czy da się zrobić "mount -o remount -r ..." (przemontować na readonly) dla sprawdzania przez fsck?

Wtedy widz mógłby sobie przynajmniej odtwarzać player-em nagrane wczesniej audycje tv podczas gdy fsck by robił swoje...

Powyższe to, co napisałem się tutaj kłania.

Widzą, że tak robi skrypt  /etc/init.d/gsysfscheck dla ROOTFS (remount-uje na readonly) i sprawdza. Ale jak chcę tak zrobić z "records" na ext4 to fsck nie chce wtedy się tego podjąć... :-/ Wiesz może dlaczego?

Włącz logiczne myślenie, to znajdziesz odpowiedź. Ono naprawdę nie boli! Podpowiem Ci tylko, ażebyś zwrócił uwagę, w którym momencie jest sprawdzanie FS uruchamiane i przeanalizował, dlaczego tak, a nie inaczej.

 

Z mojej strony dyskusja jest zakończona. Jeszcze chwila i będziemy wymyślać kolejne dziwactwa potrzebne jak piąte koło u wozu. W przypadkach, które opisujesz powinno się wyeliminować powody złego zachowania tunera, a nie leczyć w kółko objawy! Czasem problemem jest też użytkownik, który tak kombinuje, iż nie sposób uniknąć złego zachowania. [glow=red,2,300]Wtedy to już nie pomoże nic poza zmianą użytkownika :)[/glow]

 

Zachęcam do autorefleksji i atomizacja tego, co powyżej napisałem. Zachęcam i dla dobra ekipy, i dla dobra forum (jego użytkowników), i dla Twojego dobra.

 

[Gość s6s]

Ostre słowa ale wiedz że celowo Cię prowokuję "idąc po bandzie" ponieważ chcę abyś pokazał swą wiedzę bez ogródek...

(A wykazujesz straszną nieprzyjazność wobec kogoś kto chce wykazać się jakąś inicjatywą)

 

Otóż po kolei:

 

A) inaczej nie da się zapisać ustawień Enigmy (w tym zmian listy kanałów) niż poprzez jej restart

 

B) coby nie powiedzieć nadal nie masz propozycji dla tego człowieka co mu Greterlia skanuje partycje "records" przez ponad godzinę - a bez tego etapu dekodera nie włączy (a jak nawet włączy przy wyłączeniu skanowania w konfiguracji wtedy i tak ma dysk jak odpad radioaktywny bez zabezpieczenia ;))

 

C) po prostu uprzejmie pytam czy da się zrobić "mount -o remount -r ..." (przemontować na readonly) dla sprawdzania przez fsck- jak nie to trudno i przyjmuję "odpowiedź" z pokorą...

 

D) po prostu grzecznie pytam czy można w jakiś sposób bezpiecznie szybko przerwać fsck - jak nie to trudno, ale...

 

E) ...przecież nadal mamy możliwość aby sprawdzanie 'fsck' sobie działało podczas standby - po wcześniejszym przeanalizowaniu czy "Timers" nie maja zbyt niedalekiego wpisu 

 

F) Twój skrypt sprawdza ROOTFS po wcześniejszym przemontowaniu jako "readonly" na samym początku - ale mam niejasność czy wówczas na tamtym etapie czegoś nie odczytuje z nośnika?

 

Więc pragnę tylko spytać, a tu... po co tyle nerwów...

 

Pozdrawiam

[tux]

Przypadków, gdzie dysk musi być sprawdzony, bo jest dużo błędów jest niezmiernie mało. Nie piszę, że ich nie ma, ale jest mało!

Na stronie wyraźnie jest zalecane ext3/4 a nie ext2. W przypadku ext2 zawsze trzeba wykonać pełen skan nośnika - to może trwać faktycznie długo. W przypadku ext3/4 skanowanie w 95% przypadków będzie trwało chwilkę.

Przy ilości pobrań GOS na poziomie kilku tysięcy miesięcznie te kilka przypadków z forum to naprawdę niewiele. ext3/4 potraktowane "z wtyczki" naprawdę szybko jest skanowane - wyjątek - niestabilna praca systemu i błędy podczas normalnej pracy. Jednak czy niestabilna praca tunera kilku % użytkowników ma powodować, iż ktoś będzie wywracał całe GOS do góry nogami?

Tutaj dodam też, iż nawet NTFS przy dużej ilości błędów jest bezużyteczne i nawet Microsoft Windows wyświetla wtedy śliczny niebieski ekran, którego nie da się wyłączyć naciskają dowolny klawisz (niektóre takie ekrany można pominąć).

Na wyświetlaczu pojawiają się u nas konkretne komunikaty - na VFD całe opisy, na LED skróty. Było to opisane.

Tu jeszcze takie info z mojej strony - develowy DSI-87 ma pendrive 32GB. Idąc tym tropem co pisze @s6s, to powinienem co wtyczka z gniazdka czekać po kilka minut na przeskanowanie FS. Jednak przy ext4 trwa to może 3-4 sec a system plików nie był odmontowany poprawnie. Takich operacji ten pendrive przeżywa niejednokrotnie po kilkadziesiąt dziennie.

 

Teraz bardziej szczegółowo.

Ad A → wybacz - napisz co takiego wykonałeś dla GOS? Może chociaż ze dwie linijki jakiegoś skryptu? Póki co od tygodni piszesz to co jest Tobie potrzebne i chciałbyś, aby to coś podnad wszelką wątpliwość znalazło się w GOS. Mało tego nie tylko ja odnoszę to wrażenie, ale też wiele innych osób piszących do mnie PW - czytasz to i owo po internecie i potem opierając się na tym, co przeczytałeś twierdzisz, iż coś A albo B. Jednak piszesz to nim osobiście sprawdzisz. Nas tutaj zaś traktujesz jak osoby, które nie mają nic lepszego do roboty jak wieczne odpowiadanie na Twoje pytania i - jak to sam określiłeś - celowe prowokacje "idące po bandzie". Może nie było, by to nic złego, gdyby te pytania były "normalne" a nie coś w formie pobożnych życzeń połączonych z częściowym wymaganiem czegoś od NAS. A wiedza kosztuje co najmniej czas i bynajmniej nie jest rozdawana na tacy, bo tak Ci się to podoba.

 

Ad B → użyć ext3/4 i używać tunera normalnie. Jeżeli nadal będą co chwilę problemy z FS, to naprawić tuner (czytaj: sprawdzić go od strony technicznej). Nie jest normalnym zachowanie, gdzie co restart/ponowne uruchomienie mamy skanowanie dysku. Ta operacja w normalnych warunkach musi trwać w sumie moment. Jeżeli używasz innego Oprogramowania niż GOS upewnij się, że tam poprawnie jest obsługiwany dysk. Jeżeli nadal uważasz, że skanowanie dysku jest uciążliwe I KONIEC - wyłącz je w system.conf - będzie jak u innych.

 

Ad C → czy my (ja) jesteśmy (jestem) największą książką Systemów Operacyjnych? Skoro potrafisz tak szukać w internecie wszelakich informacji, to powinieneś znaleźć samemu informacje na temat tego pytania. Podpowiedź - czy możesz wykonywać działania Low Level na używanym FS?

 

Ad D → fsck póki nie zakończy swoich działań nie wprowadza zmian w FS. Poza przypadkiem ręcznej naprawy FS. Dlatego możesz dać "killall fsck". Jednak w przypadku ext3/4 fsck zadziała piorunem w przypadku autonaprawy, a w przypadku konieczności ręcznej naprawy i tak musisz widzieć, co się dzieje. Możesz co prawda przerwać skanowanie i wymusić zamontowanie partycji dysku, ale już wiele razy pisałem, czym się to skończy. Pisałem też, że takich sytuacji NIE POWINNO BYĆ, a jak są, to coś jest nie tak z Boxem i nie będziemy w GOS obchodzić problemu, bo pojedyńcze osoby:

• grzebią ile wlezie;
  
• mają niesprawne technicznie odbiorniki, które jeszcze działają, ale prędzej czy później rozsypią się do końca.
  

Ad E → ale po co skanować na zapas? Póki nie dzieje się nic złego technicznie z Boxem, a my nie uskuteczniamy NIE WIEM CZEGO, to prawdopodobieństwo uszkodzenia systemu plików jest ZEROWE! Prędzej skupiłbym się na okresowym odpalaniu testu S.M.A.R.T.

 

Ad F → skrypt odpalany jest na tyle wcześnie, że nie mamy na systemie pootwieranych plików. Możemy jeszcze zastosować RO. Później → poczytaj - ja nie mam czasu na naukę podstaw Systemów Operacyjnych i Systemów Plików. W internecie jest dostatecznie dużo informacji na ten temat. Trzeba tylko umiejętnie szukać lub włączyć samodzielne, acz logiczne myślenie.

 

Więc pragnę tylko spytać, a tu... po co tyle nerwów...

 

Problem nie w tym, że zadajesz pytania. Problem w tym, że nie myślisz, jak to robisz. Zadajesz je dlatego, że nie masz zielonego pojęcia o tym, czy o tamtym. To można uszanować, ale w jakimś dziale "żłobek" jakieś dystrybucji Linuxa. Tu nie zajmujemy się aż tak podstawowymi sprawami. Nie ma po prostu nikogo, kto ma siły na pociągnięcie tego działu.

Pytania jakie zadajesz są na tyle podstawowe, że nawet nie wiem jak mam pisać. Do tego dochodzi brak logicznego myślenia. Ja rozumiem, że możesz czegoś nie wiedzieć i chcieć zgłębić wiedzę, ale "DO DIABŁA" jak zapytam mojego 10-letniego syna, co się stanie jak będziesz próbował odmontować/przemontować używaną właśnie partycję dysku, to zna odpowiedź. Internet też zna odpowiedź. Logicznie myśląca osoba znajdzie tą odpowiedź po chwili namysłu, bo wystarczy pomyśleć tak - czy mogę wyjąć klocek z pudełka jak ktoś na nim stoi? Pewnie, że mogę, ale ktoś musi zejść z tego pudełka. Podobnie jest z FS. Ale...

 

@s6s → Czy ty naprawdę nie widzisz, że:

• albo zadajesz pytania, na które dziecko znajdzie odpowiedź;
  
• albo zadajesz pytania, które mają za zadanie doprowadzić do wypracowania metody obchodzenia problemu;
  
• albo zadajesz pytania, które mają doprowadzić do zaspokojenia Twojej elementarnej wiedzy, ale to nie żłobek;
  
• albo zadajesz pytania po to, by ktoś za Ciebie zrobił coś pod Ciebie, bo Ty uważasz, że to może być potrzebne innym;
  
• albo zadajesz pytania z lenistwa lub po uprzednio stworzonych przez siebie problemach (tych na własne życzenie).
  

Wykazałem wyżej, odpowiadając na Twoje punkty, gdzie źle myślisz i jakie błędy popełniasz. Nie zamierzam dalej dyskutować z Tobą na tej zasadzie. Nie trafiają do Ciebie żadne argumenty, które tu są pisane i dodatkowo wypowiadasz się za dużą liczbę osób, która (w tym konkretnym przypadku), to dosłownie kilka osób na tysiące pobrań. Oni też są ważni, ale pod warunkiem, że chcą szukać i myśleć. Dodatkowo sprawa sprawdzania systemu plików wykazała coś jeszcze - ludzie uświadomili sobie, że mają Dysk Twardy i on może mieć błędy, które wpływają na stabilność OS. Wcześniej większość osób nie była najprawdopodobniej nawet w jednym procencie świadoma, że tak jest. Za to po forach jest masa wpisów, że Tuner niestabilny, że się wiesza, że nie działa to czy tamto. Odpowiedzi udzielają też często osoby, które mają taką wiedzę, jaką mają i całość kręci się jak się kręci. Fałszywe wnioski tworzą kolejne.

Dzięki podejściu takiemu, jakie mamy w kwestii OS na Tunerze jest, jak jest i rzadko czyta się, że coś nie działa jak powinno (pomijając to nad czym jeszcze pracujemy).

 

Temat zamykam, ponieważ dyskusja dalsza nie ma sensu. @s6s i tak będzie szukał dziury w całym i na podstawie swoich "przeżyć" z GOS i tunerami będzie będzie pisał, że coś...

 

Na koniec: @s6s zacznij szukać wiadomości we właściwych miejscach w sieci, zacznij myśleć szerzej, albo najzwyczajniej w świecie daruj sobie zabawę z maszyną, która ma na pokładzie system operacyjny umożliwiający dostosowanie go do jednostki, przestań się męczyć, a wszyscy odetchniemy.

 

PS.

Jak można przyznać się, że się prowokuje "idąc po bandzie" i jeszcze w tym samym wpisie dziwić się, że mogą pojawić się nerwy? To nie Ty potem czytasz gros wiadomości od użytkowników (swoją drogą pozdrawiam ich), że nie powinienem Tobie odpowiadać. I fakt, prawie od początku sądziliśmy, iż prowokujesz, albo masz za zadanie pochłaniać nasz czas. Gdyby tak każdy oznaczał się brakiem szacunku do ekipy, to ona by nic innego nie robiła, jak tylko odpowiadała na rzesze niewłaściwie postawionych pytań. Czy to jest wobec nas, a przede wszystkim użytkowników w porządku? O co faktycznie Ci chodzi? Albo prosto na ławę, albo wcale.