On Thu, 09 Nov 2023 05:47:50 GMT, Marcin Debowski wrote:
> 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? :)

Chyba raz widziałem w działaniu, moglem tez czytac opinie tych, co
musieli użyc ..

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

Akurat dawniej był zazwyczaj jeden, dzis to sie chyba ext2 nazywa.

Unixy juz sie dorobiły undelete, czy nadal niekoszerny?

>>> 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?

SSD/Flash ma duzą wade - w pamięci są dosc duze bloki, po kilkaset kB,
które można skasowac w całosci, a potem mozna wpisywac i dopisywac
dane, ale nie można ich zmienic.
Chcesz np zmienic długosc pliku w katalogu, raptem 4 bajty - nie da
sie, trzeba wczytac cały duzy blok do RAM, zmienic dane w RAM,
skasować blok, zapisac wszystkie dane co tam były i powinny być z
pamięci. W dodatku bloki sie zuzywają dosc szybko (około 10 tys
zapisów), wiec popularne obszary najlepiej zapisac na nowym bloku.

Wiec nie dziwi chęc odłozenia zapisu mozliwie długo

No i w tych hybrydach do SSD trafiają chyba czesto odczytywane pliki.
Taki cache.

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

Tak, wstepna alokacja ma sens, pisałem o tym.
Myslałem, ze co innego masz na myśli.

No ale przydałoby sie chocby wiedziec jak długi ten plik bedzie, a
tradycyjne API tego nie robią.
Akurat w rejestratorach sporo plików moze miec podobną dlugośc,
bo to np będzie jedna klatka, czy 1 minuta filmu ...

>> Ale niektóre monitoringi to mialy np 4 klatki/s na kanał.
> Nie watpię, ale obecnie to 10-25kl/s jest raczej standardem.

Im wiecej, tym większy sens mają "filmowe" formaty/kompresje.

J.