JFS dla partycji "records" - nie lepiej?

[Gość s6s]

Pytam o to w sąsiednim wątku ale wszyscy to olewają, a to chyba ważne pytanie - szczególnie w nBox który daje dobrą jakość obrazu ale jednak ma słaby procek...

System plików jfs widzę, że mozna montowac bez problemu w tym systemie. Jak wiadomo tenże system plików potrzebuje NAJMNIEJ CPU ze wszystkich sensownych systemów plików.

Owszem zaleca się wszędzie, żeby partycję "records" robić pod ext4 - ale przypomnijmy, że pierwotnie ten system (z Enigmą) miał służyć na wiele różnych modeli dekoderów - większość z nich o znacznie mocniejszych prockach niż ma ADB-5800.

 

Teraz właśnie chcę przekopiować około pół TERA-bajta na nowy dysk (przez kieszeń USB), większy, i niestety przekonuję się boleśnie jak WOOOLNO to sie odbywa! Patrzę gdzie WĄSKIE GARDŁO przy kopiowaniu przy pomocy polecenia "cp -a ..." i widzę, że non stop CPU na FULL! Tak sobie myślę... PO CÓŻ robię ZNOWU partycję w ext4 ???  Jakby wziąć JFS to zapotrzebowanie na pracę procesora zmniejszyłoby się wydatnie i transfer danych zwiększyłby się z obecnego 7-8MB/s do może 20 MBs (czyli tak jak na PC przez USB2)?

 

Tak samo przy codziennym nagrywaniu różnych programów... Jak się nagrywa w jakości HD to czy przypadkiem system plików ext4 nie ZŻERA nadmiernie CPU (i przez to uniemożliwia nam np. płynne oglądanie innego programu HD równolegle)?

 

 

 

[mickey]

Nbox obsługuje dysk w trybie PIO, nie działa DMA. Nie sądzę, że zmiana systemu plików coś pomoże :(

[Gość s6s]

i to dlatego że PIO procek ma non-stop na FULL przy kopiowaniu wieeelkich plików?

przecież nie chodzi o jakieś rekordy szybkości ale 8MB/s to chyba przesada? (a cały czas przy CPU na full)

 

 

[tux]

Właśnie dlatego wprowadzono tryb DMA i późniejsze!

[AbrahaM]

Właśnie dlatego wprowadzono tryb DMA i późniejsze!

 

ale żeby w XXI wieku zrobić sprzęt bez obsługi DMA, pozwolę sobie nie komentować...

[tux]

Prawdopodobnie ograniczeniem jest coś po stronie ADB. Procesor ma funkcję DMA. Załączenie jej powoduje lekko pisząc niestabilność.

[AbrahaM]

Prawdopodobnie ograniczeniem jest coś po stronie ADB. Procesor ma funkcję DMA. Załączenie jej powoduje lekko pisząc niestabilność.

 

co i tak jest epicką tragedią :(

[mickey]

Prawdopodobnie ograniczeniem jest coś po stronie ADB.

 

Jeżeli winą obarczamy ADB, to zapytam: na ESI to samo?

[tux]

Nie miałem czasu sprawdzić. Jednak całość chodzi tak płynnie, że nie ma się do czego przyczepić.

[Gość s6s]

Przepraszam ale czy do obsługi dysku ZEWNĘTRZNEGO po USB też sprzęt wykorzystuje DMA?

Ponieważ zapis do hdd na USB poleceniem "cp -a ..." obciąża procek na full właśnie...

To więc jednak może JFS by pomógł?

 

 

Tak w ogóle to PO JAKĄ CHOLE… pchać dysk twardy DO ŚRODKA dekodera skoro owe SATA nic nie daje (bez DMA) ???

Już lepiej podłączyć przez USB przenośny wygodny jakiś 1TB, w razie czego masz wszystkie nagrania programów/filmów gotowe i do przeniesienia do kolegi, i do podłączenia do PC-ta, i do podłączenia do innego dekodera np. FERGUSSONa, a nawet do TELEWIZORA BEZPOŚREDNIO - przecież większość odbiorników TV na rynku teraz mają USB i odtwarzacz wideo...

 

Edit: Przekleństwo.

[tux]

Jest tylko jedno ale :)

Większość tych odbiorników nie osługuje ext2/3/4. Dlaczego? To już inna bajka.

 

EDIT tux:

Dla ESI-88

tuxish-ESI88-NORBox:/hdd# dd if=/dev/zero of=swapfile bs=1024 count=524288
524288+0 records in
524288+0 records out
536870912 bytes (512.0MB) copied, 40.429680 seconds, 12.7MB/s
tuxish-ESI88-NORBox:/hdd#

Raczej dla ESI-88 nie ma dskusji co do tego cz dysk pod Sata czy nie :)

[Gość s6s]

536870912 bytes (512.0MB) copied, 40.429680 seconds, 12.7MB/s

 

istotne jakie wykorzystanie CPU przy tym kopiowaniu...

 

 

[tux]

Oczywiscie ze 100%. Podobnie masz na komputerze :-).

Tyle ze tu jest to przydzielane dynamicznie i nie odczowasz tego az tak.

[mickey]

Tak tylko informacyjnie: Na 5800SX to przedstawiona przez tuxa operacja pozwalała osiągnąć co najwyżej ok. 2,5 MB/s - http://forum.xunil.pl/index.php?topic=133.msg1642#msg1642

 

@s6s: A może byłbyś chętny spróbować sformatować dysk na JFS, żeby sprawdzić, czy to coś daje?

[Gość s6s]

@s6s: A może byłbyś chętny spróbować sformatować dysk na JFS, żeby sprawdzić, czy to coś daje?

 

OK, oto moje testy.

 

- partycja "records" ext4 na SATA wewnątrz nBoksa:

Adb_Box:~# dd if=/dev/zero of=/media/hdd/plik_probny  bs=1024 count=66622
66622+0 records in
66622+0 records out
68220928 bytes (65.1MB) copied, 15.444474 seconds, 4.2MB/s

 

- partycja JFS na hdd przez USB:

Adb_Box:~# dd if=/dev/zero of=/mnt/b6/plik_probny  bs=1024 count=66622
66622+0 records in
66622+0 records out
68220928 bytes (65.1MB) copied, 9.096224 seconds, 7.2MB/s

 

-partycja ext4 na hdd przez USB:

Adb_Box:~# dd if=/dev/zero of=/mnt/b5/plik_probny  bs=1024 count=66622
66622+0 records in
66622+0 records out
68220928 bytes (65.1MB) copied, 15.948814 seconds, 4.1MB/s

 

Tak więc jasno widać, że JFS daje prawie dwukrotnie lepszy wynik niż ext4.

(Tylko jeszcze nie wiadomo czy polecenie 'dd' zachowuje się tak samo jak 'cp'? Przeciez nie kopiujemy nagrań za pomocą 'dd'...)

 

 

PS. taki "drobny" problem, że na tux-mod nie chce montować jfs, kernel nie obsługuje? Te próby robię spod Hyperiona...

 

PS-prim. JFS jest BEZKONKURENCYJNIE szybszy tam gdzie mamy słaby CPU - jedyna chyba jego wada to podatność na fragmentację - ale akurat w takim zastosowaniu tj. w przypadku wielkich plików-nagrań które raz nagrane leżą tam na dysku praktycznie wiecznie to... co się ma fragmetować? JFS wydaje się IDEALNYM systemem plików dla nBoksa! Skromnie niniejszym postulowałbym u Szanownego Tux'a o włączenie opcji/modułu w kernelu dla JFS ;)

 

 

--------------------------------------------------

jeszcze testy przy różnych wartościach "bs"

pierwszy wynik dla ext4

a drugi dla JFS

 

- przy bs=512

Adb_Box:~# dd if=/dev/zero of=/mnt/b5/plik_probny  bs=512 count=66622
66622+0 records in
66622+0 records out
34110464 bytes (32.5MB) copied, 13.070856 seconds, 2.5MB/s

Adb_Box:~# dd if=/dev/zero of=/mnt/b6/plik_probny  bs=512 count=66622
66622+0 records in
66622+0 records out
34110464 bytes (32.5MB) copied, 6.554434 seconds, 5.0MB/s

 

- przy bs=2048

Adb_Box:~# dd if=/dev/zero of=/mnt/b5/plik_probny  bs=2048 count=66622
66622+0 records in
66622+0 records out
136441856 bytes (130.1MB) copied, 21.229620 seconds, 6.1MB/s

Adb_Box:~# dd if=/dev/zero of=/mnt/b6/plik_probny  bs=2048 count=66622
66622+0 records in
66622+0 records out
136441856 bytes (130.1MB) copied, 15.657718 seconds, 8.3MB/s

 

Pytanie: jaka wartość 'bs' najbardziej odpowiada sytuacji narywania audycji TV w jakości HD?

 

 

[tux]

A sprawdziłeś odporność systemu plików na działania nieoczekiwane typu zanik napięcia zasilania podczas nagrywania?

[Gość s6s]

tux, przecież to JFS (a więc ma journalling) więc jego odporność na niezamknięcie systemu winna się równać ext4

 

a jeżeli nawet to trzeba jeszcze wyposażyć system w fsck.jfs

 

a Ty co powiesz na ten temat?

 

 

[tux]

Oczywiście dyskutować można długo. Można też tworzyć table itd.

Niestety → póki czegoś nie stracisz (lub nawet wszystkiego) to nie docenisz pewnych kwestii.

• JFS ma dziennik ale bardzo ubogi. Nie służy on w sumie do tak zwanej autonaprawy.
  
• Ext2 nie ma w ogóle dziennika i cokolwiek się dzieje to fsck.
  
• Ext3 ma całkiem niezły dziennik i odporność na uszkodzenia. Niestety kosztem prędkości. Nie jest tak szybki jak JFS.
  
• Ext4 to bardzo wydajny system plików z bardzo rozbudowanym systemem dziennikowania i nazwijmy to logiki powierzchni dysku. W skrócie można napisać, iż zapobiega na tyle ile się da fragmentacji partycji dysku. Fragmentacja wbrew pozorom ma znaczenie. O ile dla wydajności w przypadku nBoxa ma to niewiele wspólnego o tyle na żywotność samego HDD to znaczenie staje się kluczowe.
  
• XFS to chyba najlepsze rozwiązanie. Idealny system plików bowiem stworzony z myślą A/V i wydajnych serwerach plików. Idealnie obsługuje WIELKIE partycje i pliki. Ma jednak tą samą wadę co JFS - brak odporności na problemy z zasilaniem.
  

Każdy może wybrać coś dla siebie. Ja mogę dokompilować w wolnej chwili systemy plików. Problem w tym, że dla samego zapisu w nBox nie będzie to miało znaczenia bowiem nawet biorąc pod uwagę kanał HD z przepustowością 15Mbp/s (marzenie PL - średnia to 4-6Mbp/s) to zapis mamy na poziomie 1,5MB/s. Nie pisząc już o tym, iż zapis nie odbywa się w sposób ciągły. Mając duży HDD w nBox i tak po LAN nawet z prędkością 100Mbp/s nie wytrzymamy kopiując.

Dlatego uważam, że zaczynamy już lekko popadać w paranoję cyferek.

Ext3/Ext4 są jak skała. Kompatybilność prawie 100% ze wszystkim, a Ext3 w sumie 100% bo nawet pod Windows się da.

[mickey]

Jak chodzi o ext3/ext4 a dysk służy tylko do gromadzenia nagrań, to pewnie można by zmniejszyć obszar zarezerwowany: tune2fs -m 1 /dev/sda1? Jeżeli wstawię -m 0, to mogę się spodziewać problemów, czy też powinno być ok?

[Gość s6s]

Można też tworzyć table itd.

table to co to jest, zapobiegnie problemom w razie power-failure?

 

• XFS to chyba najlepsze rozwiązanie. Idealny system plików bowiem stworzony z myślą A/V i wydajnych serwerach plików. Idealnie obsługuje WIELKIE partycje i pliki. Ma jednak tą samą wadę co JFS - brak odporności na problemy z zasilaniem.

Ja mam w kompie XFS jako główny fs na wszystkich niemal partycjach i często mi padało zasilanie i system wstawał, sam się naprawiał - ZERO problemów! (od trzech lat)

 

Tylko jakie ma XFS zapotrzebowanie na czas CPU - względem JFS?

 

Każdy może wybrać coś dla siebie. Ja mogę dokompilować w wolnej chwili systemy plików.

Pleeeeeeease, DO IT! ;)

To chyba nie zajmie wiele miejsca?

 

Problem w tym, że dla samego zapisu w nBox nie będzie to miało znaczenia bowiem nawet biorąc pod uwagę kanał HD z przepustowością 15Mbp/s (marzenie PL - średnia to 4-6Mbp/s) to zapis mamy na poziomie 1,5MB/s. Nie pisząc już o tym, iż zapis nie odbywa się w sposób ciągły.

Tak, ale właśnie sprawdzam jak się zachowuje PERMAMENT TIME SHIFT z partycją "records" na JFS => BAJKA!

Te dotychczasowe problemy ze stabilnością PTS

(które na nBoksie pomimo ciągłych starań deweloperów NADAL występują w całej okazałości!)

najwidoczniej powoduje prawdopodobnie nagły SKOK zapotrzebowania na CPU (w momencie zaczynania PTS).

 

Po zastosowaniu JFS problemy ze stabilnością PTS ZNIKAJĄ!

 

Mając duży HDD w nBox i tak po LAN nawet z prędkością 100Mbp/s nie wytrzymamy kopiując.

JEDNAK jeszcze raz: jak masz hdd zewnetrzny przez USB i sformatujesz go na JFS do OSZCZĘDZISZ czas DWUKROTNIE!

Sam powiedz czy nie warto?

 

 

[tux]

Mimo iż nadal mnie nie przekonałeś, dla świętego spokoju, dodamy obsługę JFS i innych do nowej wersji systemu. Sprawa ląduje na liście ToDo. Proszę się jednak nie przyzwyczajać do tego, że wszystko będziemy robić w ten sposób. Po prostu nie mam czasu, chęci i sił na wyjaśnianie tej kwestii…

 

 

Edit: Poprawione błędy.

[Gość s6s]

Tux, i tak wielkie dzięki ;)

Porobimy jeszcze testy szybkości dla xfs, może akurat ten system okaże się najlepszy?

 

A co do JFS i PermamentTimeShift... to możeby wydzielić osobną partycję specjalnie dla PTS (oczywiście sformatowaną w JFS)?

Ponieważ dla PTS nie trzeba nic trzymać nic na stałe to więc taka partycja miałaby charakter typowo TYMCZASOWEJ. Toteż możnaby ją rutynowo przy każdym boot zwyczajnie SFORMATOWAĆ (formatowanie półterabajtowej partycji w JFS trwa parę sekund).

 

Tylko ile miejsca należałoby zarezerwować dla PTS, tak z marginesem błędu? Ile MB przestrzeni dyskowej przypada na np. na minutę nagrania w jakości HD? ;)

 

---

 

właśnie sprawdzam i przypada tak około gigabajt na kwadrans nagrania...

 

 

 

 

[mickey]

1GB/godz. to ok. 2,4Mbit/s

 

Dobrej jakości kanał HD ma jakieś 12Mbit/s, czyli ok. 5GB/godz.

 

---

 

Mnie s6s nawet przekonał do użycia JFS na partycji records, ale pewnie czegoś nie wiem...

 

Rozumiem, że problem dotyczy dwóch "drobnych" szczegółów: fragmentacji i zachowania przy braku zasilania?

 

Do defragmentacji pewnie są narzędzia i trzeba by było pamiętać o niej co jakiś czas?

 

A braki zasilania: Co mi właściwie grozi jak wyłączą prąd podczas nagrania? Stracę to jedno nagranie, czy cały dysk może się posypać? W takiej sytuacji pewnie byłoby wskazane fsck przed startem enigmy?

 

---

 

Czy do Gratelia 1.0.0 wystarczy dokompilować moduł ko i narzędzia, żeby działał JFS, czy konieczna jest kompilacja całego systemu?

[Gość s6s]

1GB/godz. to ok. 2,4Mbit/s

Dobrej jakości kanał HD ma jakieś 12Mbit/s, czyli ok. 5GB/godz.

Przekreciłeś: nie GB/h lecz GB/kwadrans, czyli czterokrotnie więcej, czyli mniej więcej się zgadza z Twoimi wyliczeniami;)

 

Teraz własnie testuję, osobna partycja na TS trzy dychy GB w JFS i osobna na "records" prawie pół TB w ext4 lecz sformatowana z opcjami pod wielkie pliki:

mkfs.ext4 -m0 -Ndefault#/2 -Lrecords -O extent,dir_index,large_file,sparse_super,uninit_bg /dev/sda6

oraz montowana z 'data=writeback'

 

Rezultat: TS ładnie i płynnie pracuje jak nigdy dotąd, od razu zamraża obraz przy wywołaniu bez żadnej rozpaczliwej "szamotaniny" jak przedtem...

Jednoczesne oglądanie z TS ok - wszystko w HD...

 

Szczególnie właśnie do TS się JFS chyba nadaje, zauważ, że przy TS operacje dyskowe występują wyjątkowo intensywnie, jednocześnie nagrywanie, odtwarzanie i kasowanie tego samego pliku.

 

A! okazuje się, że mamy też nowszą rozszerzoną wersję zwaną JFS2 aka "Enhanced JFS":

http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.baseadmn/doc/baseadmndita/fs_jfs_jfs2.htm

 

(Tam też piszą, że obie wersje JFS mają funkcję pt. "online defragmentation" tylko trzeba skołować program który to robi...)

 

 

 

[Gość s6s]

Specjalnie dla przejrzystości w osobnym poście... otóż kolejny eksperyment pokazuje, że JEDNAK "records" w JFS ma NIEZAPRZECZALNĄ zaletę!

 

Otóż w ext4 jak włączam nagrywanie dwóch kanałów HD naraz to... LIPA! obraz się rwie i szatkuje...

 

Jak jednak "records" mam w JFS to mam NARAZ włączone nagrywanie TRZECH róznych kanałów HD (dwóch kodowanych i jeden FTA) i oglądam sobie jeden z nich i obraz pokazuje SPOKO: PŁYNNY a htop pokazuje CPU=osiemdziesąt procent...

 

Tak więc Panowie... Jeżeli ktoś chce nagrywać i oglądać nawet trzy kanały HD naraz to TYLKO JFS!!!

 

---

Tylko jeszcze nie wiem czy warto robić osobną partycję dla Permament Time Shift, skoro obie: i 'records' i dla PTS mają mieć ten sam system plików...

Jednak może lepiej dla stabilności i zminimalizowania fragmentacji rozdzielić operacje dyskowe gdzie tylko się da? Jak myślicie?

 

[tux]

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).

[tux]

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

[Gość s6s]

to co do awaryjności to nawet w Twoim systemie (także w Hyperionie, Freeboksie itd) dostarczono takie narzędzie:  fsck.jfs 

Jak się ono zachowuje, czy ktoś może próbował?

 

 

[tux]

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

po przeczytaniu postu z testami:

 

Tak ale czy odłączenie anteny itd. nie sprawiło, że procek miał więcej "rezerwy" - bo przecież co do JFS to wszędzie właśnie za to chwalą ten system plików, że nie ma równej sobie konkurencji co do zjadania CPU?

 

Jak sformatowałeś i zamontowałeś ext2, z jakimi opcjami, jaką wielkością partycji?

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.

 

[Gość s6s]

-----------------------------------

po przeczytaniu postu z testami:

 

Tak ale czy odłączenie anteny itd. nie sprawiło, że procek miał więcej "rezerwy" - bo przecież co do JFS to wszędzie właśnie za to chwalą ten system plików, że nie ma równej sobie konkurencji co do "zjadania" CPU?

 

Jak sformatowałeś i zamontowałeś ext2, z jakimi opcjami, jaką wielkością partycji?

 

-----------------------------------

P.S. Czym się różnią te dwa kernele:

  kernel-jfs-mod_xfs-mod_reiserfs-mod.tar.gz (2302.5 kB)

  kernel-jfs_xfs_reiserfs.tar.gz (2229.26 kB)

tj. za co odpowiada przyrostek "mod" w nazwie tego pierwszego?

 

 

 

 

 

[tux]

P.S. Czym się różnią te dwa kernele:

  kernel-jfs-mod_xfs-mod_reiserfs-mod.tar.gz (2302.5 kB)

  kernel-jfs_xfs_reiserfs.tar.gz (2229.26 kB)

tj. za co odpowiada przyrostek "mod" w nazwie tego pierwszego?

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

 

[Gość s6s]

że systemy plików sa jako moduły do ręcznego załadowania.

a, że zajmują niepotrzebnie RAM (jeżeli nieużywane)?

 

Różne artykuły i benczmarki wygugalne pokazują, że rzeczywiście ext2 może potrzebować nawet jeszcze troszkę mniej CPU niż JFS, choć nie we wszystkich operacjach i tak mniej-więcej mają podobne zapotrzebowanie.

 

Pewnie warto sprawdzić jak się zachowa ext2 w partycji wyłącznie dla Permament Time Shift.

 

Jednakże chyba nie proponujesz aby zrobić półtorabajtową partycję na nagrania w ext2?

JFS ma jednak jakiś journalling i jakieś tam zabezpieczenie przy utracie zasilania - ale ext2 nie ma NIC!

 

Przyznasz chyba, że z tych dwóch systemów: JFS i ext2 w razie wyłączenia prądu to ten pierwszy daje większe szanse na odzyskanie plików-nagrań?

 

OK, a co z JFS2? Ta nowsza wersja "enhanced JFS" może jeszcze lepiej się zachowuje?

 

---------

Proszę, napisz jeszcze czy opcja montowania noatime (albo inne dla ext2) ma jakieś znaczenie dla PTS?

 

 

[tux]

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.

[Gość s6s]

wiesz co, sprawdzam własnie poleceniem:

dd if=/dev/zero of=/mnt/partycja bs=1024 count=66622

dla dwóch partycji: jedna ext2 a druga JFS

i tak wielokrotnie, i wyniki wyskakują różne ale oscylują dla obu systemów plików wokół tej samej wartości: 8 MB/s

 

Tak więc szybkość obu dla słabego procka plasuje się prawdopodobnie tak samo, jednak nie mogę oprzeć się wrażeniu, że PTS jednak STABILNIEJ pracuje na JFS bo na ext2 znowu zaczynaja się ta irytująca NIEPRZEWIDYWALNOŚC kiedy się zatrzyma obraz i za którym razem itd...

 

 

 

 

[tux]

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.

[Gość pppp]

sprawdzilem jfs i ext2 z punktu widzenia sprawności PTS

to bez róznicy takie same przypały a skoro wyniki dla ext2 są lepsze

a dziennik jfs to fikcja (jeśli jest jak mówi tux)

no to bez sensu bawic sie w jfs. Lepiej zostawić chyba ext2

 

Powiem wiecej:

Na ext2 z pts nie ma problem "nakładania się ostatniego obrazu z tym przewijanym jakby z przeplotem"

a na jfs mialem to. Oczywiście efekt nalezy testować na kanalach HD. Na SD nie wystepuje problem.

 

I w tym momencie jestem kupiony przez ext2 :)

 

PS.

Podpowiedz. Sformatować dysk można po jego odnontowaniu tylko.

Odmontować mozna gdy dysk jest nie zajęty. A dysk jest zajęty przez PTS

Robię więc tak, że zmieniam kanał i w tym momencie z konsoli daje unmount zanim pts sie zabierze

do dysku. Wtedy można reformatowac na jfs lub ext2

 

 

[tux]

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.

[Gość pppp]

"fikcja" w kontekscie zastosowania w nbox a dokladniej partycji dla recordingu oczywiście :)

 

 

[Gość s6s]

owszem, po dłuższym uzywaniu musze potwierdzc, ze ext2 i JFS dla PTS sie podobnie zachowuja lecz nadal twierdze ze stabilniej niz ext4

------------------------------

Przed chwilka nbox sie zawiesil i po restarcie polterabajtowa partycja z JFS nie chciala sie zamontowac. Jadnak fsck.jfs naprawil system plikow w trzy sekundy doslownie (w nBoksie).

 

Jezeli fsck.jfs tak sprawnie naprawia to moze jednak zastanowicie sie ponownie nad wykorzystaniem JFS?

 

Przeciez co za problem zadac aby fsck.jfs sie wywolywal automatycznie przy starcie? Rzadko sie to wszak zdarza, za startujemy nBoksa po wylaczeniu, na ogol trzyma sie go w standby.

 

 

[Gość pppp]

Sie uparłeś na jfs

W kontekscie PTSa (a wiec recordingu) jfs jest gorszy od ext2. Zarówno transferem jak i efektem "przeplotu" na HD

To po cholere głowę sobie nim zawracać?

 

 

 

 

[tux]

@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!

[mickey]

Podsumowując z poziomu zwykłego użytkownika jak ja :P:

• Zalecanym systemem dla partycji records pozostaje ext4. Jego zaletą jest odporność na uszkodzenia, które mogą nastąpić po awarii zasilania. Wadą: duże obciążenie procesora.
  
• Aby zmniejszyć obciążenie procesora formatujemy partycję records na ext2. Robimy to na własne ryzyko związane z możliwą awarią systemu plików przy odłączeniu zasilania.
  
• Po awarii zasilania logujemy się na konsolę i wykonujemy kolejno (zakładając, że records mamy na /dev/sda1): 1) umount /hdd, 2) fsck /dev/sda1, 3) mount /hdd.
  

Jeżeli coś pomieszałem, to poprawcie mnie.

[Gość pppp]

Dobrze prawisz mickey. Jedynie odmontowanie gdy chodzi pts moze byc problemem. Opis wyzej

 

 

[mickey]

OT ... a może jednak nie. Z ciekawości chciałem sprawdzić mój dysk sformatowany na ext4 a w wyniku zobaczyłem na ekranie:

nbox:~# fsck /dev/sda1
fsck 1.41.14 (22-Dec-2010)
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Group descriptors look bad... trying backup blocks...
One or more block group descriptor checksums are invalid.  Fix<y>?
(...) [linii podobnych do poniższej było duuużo] (...)
Group descriptor 7452 checksum is invalid.  FIXED.
records contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error allocating block bitmap (1): Memory allocation failed
e2fsck: aborted

Dysk wydaje się działać całkowicie poprawnie...

[Gość s6s]

@s6s → a ile danych miałeś na tej 0,5TB partycji? Pyło tam chociaż 300GB?

Jeszcze nie, przecież mam ją sformatowaną od przedwczoraj.

Jednak co w tym wypadku się bardziej liczy: ilość miejsca zajętego czy ilość plików? Podejrzewam, że sytuacja w której gromadzi się tam mała liczba wielkich plików z nie więcej niż dwoma katalogami nie należy do szczególnie trudnych.

 

Widzisz → tu już nie chodzi o JFS vs ext2. Tu hodzi o wygodę.  Przy ext3/ext4 mało jest przypadków naprawy ręcznej!

Tak ale co jakby to działo się AUTOMATYCZNIE? Przy starcie system chce jak zawsze montować partycję z JFS, jeżeli montowanie zwraca błąd to zaczyna fsck.jfs po którym zaraz sam i tak montuje.

To wszystko dzieje się W TLE kiedy użytkownik może sobie oglądać programy i nawet nic nie spostrzeże - o ile zechce cos nagrać (to wówczas wyświetli się jakiś sensowny komunikat o tym naprawianiu partycji i prośba żeby nagrywanie zaczął potem).

 

Trzeba podkreślić że omawiany scenariusz wystąpi rzadko, tylko po awarii zasilania przy pierwszym starcie systemu. O co tyle hałasu? ;)

 

JFS to system co ma journalling więc naprawa sprawia o wiele mniej problemu niż dla "gołego" ext2.

Jeszcze wartałoby być może przyjrzeć się XFS, własnie przeglądam benchmark zrobiony specjalnie dla dużych plików (trzygigabajtowych):

http://forums.anandtech.com/showthread.php?t=1144811

(w załaczniku CZYTELNA sformatowana przeze mnie tabelka w Excelu)

Pokazuje on praktycznie TAKĄ SAMĄ szybkość i konsumpcję CPU dla JFS, ext2 i XFS.

Róznice występują tylko dla kategorii:

 

- Sequential-Output:Per-Chr => JFS ma o jedną trzecią mniejszy transfer i o tyle samo mniejsze zużycie CPU niż ext2 i XFS  (pytanie: co się dzieje systemowi plików kiedy zabraknie CPU? ponieważ jak po prostu czeka to chyba tu też wszystkie systemy dadzą ten sam wynik)

 

- Sequential-Create:Create => ext2 ma CPU na full a pozostałe JFS i XPS ćwierć tego, poza tym XFS dwa i pół raza wolniejszy (tutaj więc zwycięża JFS!)

 

- Random-Create:Create => ext2 CPU na full a pozostałe poniżej połowy, XFS nawet najmniej zjada CPU bo ćwierć tego (w tej kategorii XFS najlepiej wypada a ext2 najgorzej)

 

- Random-Create:Delete => tutaj ext2 ma o rząd wielkości większą szybkość lecz CPU na FULL, podczas gdy pozostałe systemy mniej niż dwadzieścia procent (jeżeli brak CPU oznacza tylko czekanie to ext2 zwycięża a XFS najgorszy)

 

Pytanie: które z tych kategorii najczęściej występują w nBoksie przy nagrywaniu i/lub dla PTS?

 

 

 

jfs-benchmark-onerow.xls.gz

[Gość pppp]

@s6s

 

Temat jfs wydaje sie juz wyczerpany. Dostales powyzej kernel z obsługa jfs. Masz ochotę używaj.

 

 

 

[Gość s6s]

owszem uzywam :)

Tylko jak zrobić aby w razie błędu montowania przy starcie samo się zapuściło fsck.jfs a po nim znowu się samo chciało zamontować?

i to wszystko w tle, tj. żeby można sobie podczas tego niezauważenie oglądać TV?

To przecież przydałoby się tak czy inaczej gdyż problem może wystąpic i przy innych systemach plików, np. ext2, a nawet ext4.

 

Aha, jeszcze jakie opcje formatowania i montowania ext2 wybrać żeby zoptymalizować dla PTS (pod kątem transferu i CPU)?

Jakie operacje na systemie plików, jaki rodzaj zapisu/odczytu, per-char/block czy random/sequential/seek itd. dominują przy PTS a jakie przy regularnym nagrywaniu audycji TV?

 

 

 

[mickey]

Żeby fsck się zapuściło, to trzeba zmienić linię w fstab na:

LABEL=records   /hdd            auto    defaults                                                0       1

 

Czyli wpisać 1 zamiast 0 na końcu. Natomiast nie wiem co się dzieje, jeżeli automatyczne fsck nie da rady naprawić samo. Komunikat na konsoli (dostępnej przez kabelek...) i oczekiwanie na reakcję użytkownika? A wtedy pewnie nie działa SSH i system już nie wstanie?

 

Druga możliwość, to jakiś skrypt odpalany z rcS, tuż przed startem enigmy. Jeżeli status partycji (tune2fs -l /dev/sda1 | grep "Filesystem state:" | awk '{print $3}') róźny od clean, to załącz fsck -y /dev/sda1. Podczas tej operacji, przydałoby się na wyświetlaczy wypisać "sprawdzenie dysku". Zostają dwa problemy: 1) Ile to będzie trwało, 2) Jakby ktoś zerknął na mojego poprzedniego posta - u mnie nie daję rady sprawdzić systemu plików na /dev/sda1, bo zabrakło pamięci. Jeżeli opisana procedura byłaby przed startem enigmy, to dostępnej pamięci jest więcej, może wystarczająco dużo? W najgorszym razie system plików nie zostanie naprawiony a system wstanie. Wykonywanie tego skryptu można by uzależnić od jakiegoś ustawienia w system.conf...

 

---

 

Jak chodzi o opcje formatowania i montowania, to nie mam pojęcia. Ale mam dodatkowe pytanie. Szukając różnic pomiędzy ex2/ext3/ext4 znalazłem takie info: Maximum individual file size can be from 16 GB to 2 TB. Ten opis dotyczy ext2, ale dolny limit jest taki sam dla ext3 i ext4. Jak mam rozumieć te from i to? Muszę coś ustawić przy formatowaniu, żeby system plików akceptował pliki większe niż 16GB? 25GB nagrania to nie jest wielki problem...

 

---

 

OT (tym razem bardzo OT): FreeBSD odpala coś takiego jak "background filesystem check". System wstaje a jeżeli była awaria zasilania, t sprawdza sobie dyski w tle. Dysk trzeba podzielić na partycje (/, /boot, /usr, /var, ...) i na te ważne dla startu systemu w trakcie normalnego działania nic się nie zapisuje, więc się nie sypią. A jak samo się nie naprawi i nie wstanie /home czy /usr (odpukać, ale dawno - liczone w latach - mi się nie zdarzyło), to przynajmniej działa już SSH i można zrobić fsck przez sieć.

[tux]

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.

 

Jeszcze nie, przecież mam ją sformatowaną od przedwczoraj.

Jednak co w tym wypadku się bardziej liczy: ilość miejsca zajętego czy ilość plików? Podejrzewam, że sytuacja w której gromadzi się tam mała liczba wielkich plików z nie więcej niż dwoma katalogami nie należy do szczególnie trudnych.

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

 

Widzisz → tu już nie chodzi o JFS vs ext2. Tu hodzi o wygodę.  Przy ext3/ext4 mało jest przypadków naprawy ręcznej!Tak ale co jakby to działo się AUTOMATYCZNIE? Przy starcie system chce jak zawsze montować partycję z JFS, jeżeli montowanie zwraca błąd to zaczyna fsck.jfs po którym zaraz sam i tak montuje.

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ł.

To wszystko dzieje się W TLE kiedy użytkownik może sobie oglądać programy i nawet nic nie spostrzeże - o ile zechce cos nagrać (to wówczas wyświetli się jakiś sensowny komunikat o tym naprawianiu partycji i prośba żeby nagrywanie zaczął potem).

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.
  

Trzeba podkreślić że omawiany scenariusz wystąpi rzadko, tylko po awarii zasilania przy pierwszym starcie systemu. O co tyle hałasu? http://xunil.pl/forum/Smileys/akyhne/wink.gif[/img]

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.

JFS to system co ma journalling więc naprawa sprawia o wiele mniej problemu niż dla "gołego" ext2.

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?

Jeszcze wartałoby być może przyjrzeć się XFS, własnie przeglądam benchmark zrobiony specjalnie dla dużych plików (trzygigabajtowych):

http://forums.anandtech.com/showthread.php?t=1144811

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 :)

 

Pytanie: które z tych kategorii najczęściej występują w nBoksie przy nagrywaniu i/lub dla PTS?

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!

[mickey]

@tux: Temat JFSa też już u siebie zamknąłem, ale mam nadzieję, że jeszcze odpowiesz mi w tym wątku :)

 

Zamierzam zaryzykować i sformatować dysk z nagraniami na ext2 a co z tego będzie, to się okaże. Miałbym kilka pytań, dość konkretnych...

 

1) Jeżeli w /etc/init.d/rcS zakomentuję pętlę until false (u mnie od linii 442 do 505) i zrobię reboot, to nbox wstanie bez enigmy i będę mógł spróbować sprawdzić system plików na /hdd. Jeżeli też braknie pamięci, to dysk na zewnątrz i fsck pod innym systemem?

 

2) Przed startem enigmy (linia 445: /usr/local/bin/enigma2) mógłbym sprawdzić, czy system plików na /dev/sda1 jest clean a jeżeli nie to zrobić w tym momencie zrobić umount /hdd. Teraz mam problem co dalej. Pomysłów mam kilka, tylko nie wiem dokładnie w którym momencie:

 

- echo "dysk wymaga sprawdzenia" > /dev/vfd oraz sleep 5 ... jeszcze przed wywołaniem enigma2?

- później trochę ryzykowne fsck -y /dev/sda1 i mount /hdd po zakończeniu sprawdzania, za tą pętlą until false czy lepiej z rcS.users.sh?

- albo lepiej nie montować wcale dopóki ręcznie się nie zaloguję i nie sprawdzę?

 

3) Proszę o odpowiedź w sprawie maksymalnego rozmiaru pliku dla ext2/ext3/ext4. Czy trzeba coś włączyć przy formatowaniu, żeby przekroczyć te 16GB? Z tego co znalazłem, to przy tej wersji kernela, która jest w Gratelia (2.6.32) i przy rozmiarze bloku równym 4096 (tyle mam) to mam limit rozmiaru pliki 2TB. Zgadza się?

 

4) [dopisane] Mam folder /hdd a nie jest pod niego podmontowany dysk ... co się właściwie dzieje przy próbie włączenia nagrania? Zapisuje mi do NAND czy też na PENa?

 

PS. Co do mojego systemu plików i szoków. Komenda reboot kiedy enigma wisi a niby trwa nagrywania jest (no może była) u mnie normalką. Odłączeń zasilania też kilka było, ale do takiej ostateczności rzadko muszę się uciekać.