W dniu 09.11.2023 o 00:47, Marcin Debowski pisze:
>> 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.

Ja do tego AUTOPSY używam.
>
>> 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.

Tylko ja na to nie mam wpływu. Mam, co mam.
>
>> 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
> plików), ale system siłą rzeczy musi to wiedzieć już przed zapisem.
> 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.
>
>> Ale mnie sie cos wydaje, ze rejestrator moze po prostu nie wyrabiac
>> z zapisem kilku/nastu filmów naraz, wiec z załozenia zapisuje sie
>> co n-tą klatkę, a wtedy kompresje "filmowe" gorzej działają, wiec
>> lepiej zapisywać "ciąg zdjęc".
> Rejestratory mają enkodery sprzętowe. Proces kompresji wideo nie odbywa
> się na dysku. Zgaduję, bo ponownie, nie jestem ekspertem, ale pewnie
> enkoder zwraca skompresowane bloki GOP (group of pictures) i dopiero one
> są zapisywane. Jest to dla dysku duzo prostsza operacja niż otwieranie i
> zamykanie pierdyliona plików na sekundę z n-różnych kanałów, gdzie
> obecnie każdy kanał miałby przetworzyć te min. 15-25 plików na sekundę.
> Dla wideo otwarte będzie tylko n-plików (w uproszczeniu) a częstotliwość
> operacji otwierania i zamykania będzie warunkowana założoną wielkością
> pliku wynikowego (np. do 2GB).
>
> Dodatkowo, dyski z DVR/NVR nie są zwykle odczytywalne w standardowy
> sposób, tzn. mimo, że wiekszość NVR/DVR działa pod Linuksem, standardowy
> Linuks tych dysków na poziomie logicznym nie widzi. Nie chciało mi się
> nigdy w to wnikać, ale najpewniej oznacza to, że albo te dyski są
> szyfrowane, albo system plików jest niestandardowy, zoptymalizowany
> własnie pod prace z cctv.

Ze szkolenia zapamiętałem, że właśnie jest tak, że jest tablica
opisująca stempel czasu oraz adres pliku oraz pliki. W praktyce, jeśli
mam wyrwany z rejestratora nośnik, to analizuję to AUTOPSY i dostaję
milion obrazków. Te obrazki układa się na osi czasu. AUTOPSY to sobie
robi pewnie na bazie metadanych. No i teraz możemy podglądać te obrazki.

Przy czym zdaję sobie sprawę, ze standardy są bardzo różne. Ale ja nie
jestem konstruktorem rejestratorów. Po prostu czasem wyciągam z nich
dane i staram się to zrobić najlepiej, jak się da.

Czasem są sekwencje filmików. System na ządanie na zewnętrzny nośnik
archiwizuje wybrany kanał jako jeden filmik albo jako jakieś odcinki.

--
(~) Robert Tomasik