On 2023-11-09, J.F <j...@p...onet.pl> wrote:
> On Wed, 08 Nov 2023 23:47:13 GMT, Marcin Debowski wrote:
>> On 2023-11-08, J.F <j...@p...onet.pl> wrote:
>>> On Wed, 8 Nov 2023 15:36:09 +0100, Robert Tomasik wrote:
>>>> W dniu 08.11.2023 o 01:48, Marcin Debowski pisze:
>>>>>>> Przy czym sama idea jest MZ mocno takase i trochę watpie czy jest nadal
>>>>>>> powszechnie stosowana.
>>>>>> Zaletą tej idei jest to, że jeśli przerwiesz nagranie, to masz ostatnią
>>>>>> klatkę. Jak nagrywasz filmiki, to nie masz ostatniego.
>>>>> Masz, bo ramka I jest zawsze przed P i B.
>>>>
>>>> Jeśli przerwiesz w wyniku katastrofy zapisywanie filmiku, to potem się
>>>> go nie da odczytać, bo plik nie jest zamknięty. Może jest jakiś sposób
>>>> obejścia tego, ale w każdym razie z pierwszego taki problem się rodzi. I
>>>> dlatego właśnie wymyślono ten zapis klatek. Tak przynajmniej na
>>>> szkoleniu wyjaśniał to facet.
>>>
>>> System operacyjny powinien miec narzędzia pozwalające na zamknięcie
>>> pliku po awarii, ale oczywiscie koncówka może zniknąć, a w tym
>>> przypadku moze to byc dosc istotne - zeby np zdążyło sie zapisać
>>> kto wyłączył zasilanie :-)
>>
>> Jest darmowe oprogramowanie odzyskujące różne funkcjonalne pliki bez
>> udziału systemu plików. Szuka po nagłowkach i metadanych tych plików.
>
> I wychodzi mu to lepiej lub gorzej.

Skąd wiesz jak mu wychodzi? :)

>>> Mozna sie tez zabezpieczyc na inne sposoby - np alokujemy miejsce
>>> dla kolejnych danych w pliku, zapisujemy wszystkie systemowe dane,
>>> a potem tylko wpisujemy dane video.
>>> Pomysł raczej na dyski magnetyczne, bo flashe maja swoje inne narowy
>>> .. szczególnie, ze w tym "twoim" pomysle jest to samo ryzyko - dane z
>>
>> Wystarczy niebuforować operacji dyskowych. Zarżnie się tak pewnie dysk,
>> ale więcej ocaleje. Z tym, że jakieś bufory nadal będą, bo operacje na
>> tych danej wcześniej są wykonywane.
>>
>>> wszyskich klatek będą na dysku, ale zabraknie wpisów o tych plikach.
>>
>> Tak jak to opisujesz to problem jest MZ w buforze. Na tyle się na tym
>> nie znam, żeby wiedziec jak dokładnie zapisywane są na dysku dane o
>> alokacji plików (co niewatpliwie zalezy tez od konkretnego systemu
>
> W FAT wiedziałem, w Unixie wiedziałem.

Co to jest w tym Unixie bo tam trochę tych systemów plików jest...

>> plików), ale system siłą rzeczy musi to wiedzieć już przed zapisem.
>
> Ale nie musi tego od razu zapisywac.
>
> Praktycznie co blok (kilka sektorów), trzeba zapisywac kilka bajtów
> do FAT czy innej tablicy, wypadałoby zmodyfikować długośc pliku - wiec
> nic dziwnego, ze sie to odsuwa, szczegolnie ze zaraz będzie zmienione.
> Ale prawdziwy problem jest na dyskach SSD/Flash.
>
> W magnetycznym z kolei głowice się urwą :-)

Na tym polega problem z buforem. Być powień, bo inaczej głowica będzie
latać. Nb. jak to wyglada przy hybrydach hdd z ssd? Może tam by nie
latało?

>> Kwestia tylko taka, czy metadane systemu plików są zapisywane przed
>> zapisem danych czy po. Zasadniczo chyba się da przed, więc pewnie się
>> tak robi.
>
> IMO - niewielka z tego zaleta. Chyba, ze wiesz, ze kolejne dane będą w
> kolejnych sektorach.

Zaleta taka, że jak zabraknie prundu to widomo gdzie miał być zapisany
kolejny blok. Czy się zapisał to inna sprawa, ale w odwrotną stronę
nawet nie wiemy gdzie ten blok mógł sie zapisać.

> Ale niektóre monitoringi to mialy np 4 klatki/s na kanał.

Nie watpię, ale obecnie to 10-25kl/s jest raczej standardem.

--
Marcin