Прошу пораду - в виборі (камер, обладнання) для відеоспостереження за ділянкою

[Mr. D]

Існують згадування про Hikvision File System та деякі програми для відновлення даних знають про існування такої файлової системи

 

Наприклад

Filesystem Name HIK_264
Filesystem Version 2018.01.22

 

Але все одно HDD - це block-пристрій. Наприклад, невідомо використовується Hikvision FS саме в Hikvision NVR та реалізована або ні команда TRIM в Hikvision FS.

Змінено 8 січня користувачем Mr. D

[Mr. D]

23 години тому, Mr. D сказав:

Існують згадування про Hikvision File System та деякі програми для відновлення даних знають про існування такої файлової системи

 

Наприклад

Filesystem Name HIK_264
Filesystem Version 2018.01.22

 

Але все одно HDD - це block-пристрій. Наприклад, невідомо використовується Hikvision FS саме в Hikvision NVR та реалізована або ні команда TRIM в Hikvision FS.

Знайшовся ось такий цікавий документ "Analysis of the HIKVISION DVR File System" - eudl.eu/pdf/10.1007/978-3-319-25512-5_13?ref=https://githubhelp.com#:~:text=The HIKVI‐ SION file system,or change a file‐ name.
Мова йде про Hikvision DVR, тому не зовсім зрозуміло наразі така файлова система використовується в NVR або ні.
 

Цікаві тези

"The HIKVISION DVRs have no delete function" - "Функції видалення в Hikvision DVRs немає"
"When the data exceeds the capacity of the hard disk, old video data is replaced with new data" - "Коли місце в HDD закінчується, старі дані заміняються на нові" (на мою думку, це значить, що завжди використовуються одній й ті ж блоки для деяких умовних файлів, що навіть зручно SMR HDD).

Структура FS достатньо проста. Мабуть, тому програми для відновлення даних підтримують Hikvision FS.

Змінено 9 січня користувачем Mr. D

[uafisher]

В 08.01.2024 в 07:32, Mr. D сказал:

Приклади вище показують як саме працює велика частина файлових систем.

Мені не треба якісь приклади як якісь системи виконують якісь операції. Мені взагалі це питання не цікаво-воно цікаво вам. То я в третє і останнє навожу вас на такі роздуми. Ви знаєте ще таке предзапис на реєстраторах? У нас є подія, і є можливість налаштувати запис не тільки самої події - а й певний проміжок (відео/аудіо) ДО неї.
У ваших листуваннях з standov була думка, що файли на хдд реєстратор не модифікує, вірно?  Почав записувати дані, зберіг. Якщо це так - то поясніть яким саме чином відбувається пред запис. Бо мені здається модифікація файла (видалення даних) відбувається-при чому майже постійно. То що у фізично різні сектора - зрозуміло.

В 08.01.2024 в 07:43, Mr. D сказал:

Вважаю, що з точки зору звичайного побутового NVR немає різниці використовується SMR HDD або CMR HDD.
...
Якщо у Вас є посилання на відповідні матеріали WD, Seagate або іншої компанії, де зазначено, що саме HDD з технологією SMR не можуть бути використанні в NVR, будь ласка, надайте таке посилання. Мені не вдалося поки що знайти.

Ви уважно читаєте про що я пишу? Де хоть раз я вказав, що СМР не використовується у таких дисках? Чи я казав, що про це стверджує виробник? Більше того - я чітко знаю, що Сігейт у лінійці для відео використовує обидва типи - і чесно зазначає де який. 
Знову ж таке, наш колега standov відстоював заперечення щодо наявності реальної різниці: ХДД для відео і ХДД інший, у нього зводилось все лише до ЦМР чи СМР. Ну його думка та досвід) І ви також все - СМР чи ЦМР. Я не звожу тільки до цього, більше того - думаю це не головне.
Загалом мені це питання не дуже цікаво, і я не розумію сенс подальшої публічної дискусії)))  Моя позиція дуже проста: "звичайні" диски вилітають, для відео працюють. Найстаріші диски які не замінені у мене стоять на об'єктах -це приблизно 2015-206 роки-ну не можу я змусити цих людей замінити вже). Вже тоді я ставив тільки айпішні камери. На одному з об'єктів загальна кількість камер до 50, камери згодом замінювались/добавлялись, отже і каналів і трафіку там хватає.  
Нещодавно в енний раз ганяв тест на реєстраторах - по дисках ні помилок, ні бедів- нічого, запис/відтворення є). Мабуть вже коли посипляться люди схаменуться - але 6-7-8 років 24/7 з ІНТЕНСИВНИМ рухом в камерах і іх значній кількості про щось може довести. Кажу - стільки не живуть, краще міняємо поки не пізно - не міняють).
одразу скажу - якщо саме ХДД і в реєстратори -то я ставлю тільки Сігейт, ВД мені не смачні) 
Також є цікавий циркуляр, вже давно - якщо принесете до офіціалів реєстратор з проблемою запис/відтворення і диск буде левацький - мають право заявити не гарантійний випадок.
Отже, у підсумку.
Я знаю що диски для спостереження мають певні особливості, саме для роботи в системах відеоспостереження. Часто на них гарантія більше. Будуть (можуть бути) проблеми із зверненням до офіціалів. На практиці такі диски ходять довго - звичайні при аналогічному навантаження вилітають (є). То мені зараз треба повірити комусь на форумі і потім хліпати очима і казати -а Петя на форумі сказав що це все маркетинг і різниці немає?))
Отже мене не аргументували ці аргументи). Я брав і беру відповідні диски, ЦМР чи СМР, як і наповнення гелієм чи повітрям-вторинне, але я відслідковую моделі і намагаюсь купувати тільки ЦМР (перестраховуюсь).
Інші думки для мене мають право на існування але дякую, ні. 

Змінено 10 січня користувачем uafisher

[k-master]

08.01.2024 в 08:43, Mr. D сказав:

Якщо у Вас є посилання на відповідні матеріали WD, Seagate або іншої компанії, де зазначено, що саме HDD з технологією SMR не можуть бути використанні в NVR, будь ласка, надайте таке посилання. Мені не вдалося поки що знайти.

Не знайдете, бо як тоді їх продавати?

4 години тому, uafisher сказав:

Почав записувати дані, зберіг. Якщо це так - то поясніть яким саме чином відбувається пред запис. Бо мені здається модифікація файла (видалення даних) відбувається-при чому майже постійно. То що у фізично різні сектора - зрозуміло. 

Пишемо по колу, нічого не видаляємо. Кудись раз на секунду/хвилину пишемо за якою адресою на диску знаходиться ця секунда для швидкого пошуку. Якщо була подія, то просто кудись окремо пишемо час старта, час закінчення. Тобто запис подій це просто запис часу початку та закінчення, у продвинутих ще координати об'єктів. Я б зробив так, воно виглядає логічно та дозволяє писати максимальну кількість потоків на один диск. Якщо є завдання зберігати евенти щоб вони зберігались більше ніж час за котрий повністю заповнюється диск то можливі варіанти. 

[Mr. D]

8 годин тому, uafisher сказав:

яким саме чином відбувається пред запис

Якщо в час T+0 трапилася подія, яка вимагає наявності відео до часу T+0, яка максимальна кількість часу до моменту T+0 може бути збережена реєстратором? Можливо, існує буфер, який перезаписується по колу й тоді сектори перезаписуються в порядку "0 -> 1 -> 2 -> 0 -> 1 -> 2", якщо T+0 з'являється під час запису сектору 1, то послідовність "1, 2, 0" маркується як суцільна частина для збереження.

Якщо виробники інвестували в розробку або модифікацію FS, повинен бути швидкий алгоритм (в цьому й є сенс адаптації FS).

8 годин тому, uafisher сказав:

Кажу - стільки не живуть, краще міняємо поки не пізно - не міняють).

S.M.A.R.T. надає відповідну інформацію, яка в системах збереження даних є індикатором так званого Health Status, відносно якого й приймається рішення про заміну окремого пристрою.

Загалом у разі великої системи відеонагляду я би очікував побачити NAS + NFS, який працює на RAID 6+0 (або чомусь подібному). Тоді NAS повідомляє про відповідні зміни статусу окремих пристроїв.

Якщо не помиляюсь навіть достатньо прості NVR підтримують RAID 1.

Інколи так буває, що HDD, S.M.A.R.T. яких вже невідповідний, з'являються в продажу як відновлені HDD. Такі HDD ще можливо використовувати для off-line архівів, але не більше.

8 годин тому, uafisher сказав:

мають право заявити не гарантійний випадок.

HDD для систем відеоспостереження в механічній частині повинні бути схожі на диски для NAS. Але, на мою думку, NAS та NVR мають різні профілі навантаження (що відкриває можливості для швидкого маніпулювання буфером в SMR). Загалом наразі WD надає до 3-х років (або навіть більше; можливо до 5-ти) офіційної гарантії, тобто протягом 3-х років можливо очікувати, що HDD буде працювати в тому сенсі, що HDD будуть обслуговувати. На мою думку, часи безсмертних HDD вже давно пройшли та підходять часи гібридів SLC+QLC.

Змінено 11 січня користувачем Mr. D

[uafisher]

В 10.01.2024 в 22:41, k-master сказал:

Пишемо по колу, нічого не видаляємо. Кудись раз на секунду/хвилину пишемо за якою адресою на диску знаходиться ця секунда для швидкого пошуку. Якщо була подія, то просто кудись окремо пишемо час старта, час закінчення. Тобто запис подій це просто запис часу початку та закінчення, у продвинутих ще координати об'єктів. Я б зробив так, воно виглядає логічно та дозволяє писати максимальну кількість потоків на один диск. Якщо є завдання зберігати евенти щоб вони зберігались більше ніж час за котрий повністю заповнюється диск то можливі варіанти. 

Раз на секунду кудись пишемо де знаходиться ця секунда)) А коли реєстратор таймлапс записів малює-він також в цей журнал бігає?) Нащо це все городити, коли можна просто маркірувати трафік? І так це і відбувається, так система знає де початок евенту де кінець.
Потім. Коли ви виконуєте експорт файлів - чому вони різного обсягу?) Це система експортує готові файли? А ні- бо ми ж зберігаємо ВЕСЬ трафік, у якісь файли, а потім по таблиці бігаємо шукаємо секунди. А для експорту ми створюємо нові файли, без мусору-"кадрів пустишек"?) 
Ріллі?)
А коли поставили новий диск і через добу бачимо використано стільки, вільно стільки - вважаєте це не реальні цифри?) Там збережені тільки евенти чи евенти +кадри пустишки?)))))
Та ну)

[uafisher]

21 час назад, Mr. D сказал:

Якщо в час T+0 трапилася подія, яка вимагає наявності відео до часу T+0, яка максимальна кількість часу до моменту T+0 може бути збережена реєстратором? Можливо, існує буфер, який перезаписується по колу

Та я ж вище не просто так згадував, що буфер 256 мбіт на ХДД заб'ється миттєво)
У Хіка по пам'яті 60 сек можна точно, колеги нехай поправлять, перевіряти зараз облом). Берем 4-5, ок 4,5 мбітс трафік*60 сек*64 канали (допустима виробником кількість каналів на 1 ХДД, таких моделей багато). Отримуємо 2 160 Мб, що у 8 разів більше за ВЕСЬ кеш ХДД. Так є диски з 64 мб...
І...ДЕ МИ ЦЕ ВСЕ ЗБЕРІГАЄМО?)))
Створюємо файл -пишемо пустишку відеоряд-чекаємо на маркер евенту - піймали=зберігаємо пред запис та евент, немає евенту - видаляємо, ... Файл модифікується, у чому проблема?)

21 час назад, Mr. D сказал:

S.M.A.R.T. надає відповідну інформацію, яка в системах збереження даних є індикатором так званого Health Status, відносно якого й приймається рішення про заміну окремого пристрою.

От дякую, ну хоч зараз буду знати що це таке) А я думав то годинник!

21 час назад, Mr. D сказал:

HDD для систем відеоспостереження в механічній частині повинні бути схожі на диски для NAS. Але, на мою думку, NAS та NVR мають різні профілі навантаження

Це ви так вирішили? Ви праві! Ну певно, більше скажу - Ланос, Ф1 та Джип вони теж в механічній частині схожі, мають певні спільні риси та принцип дії,  аналогічні механізми, схожі елементи керування, використовують схоже пальне та навіть мають однакову кількість колес! А кольору у світі не існує взагалі!)

Може різницька все ж є, невеличка начебто). Обумовлена у т.ч. "різними профілями навантаження", про що і каже нам виробник...
Тільки от не треба нового кола обговорень, я точно не хочу.

[Mr. D]

12.01.2024 в 00:45, uafisher сказав:

Раз на секунду кудись пишемо де знаходиться ця секунда)) А коли реєстратор таймлапс записів малює-він також в цей журнал бігає?) Нащо це все городити, коли можна просто маркірувати трафік? І так це і відбувається, так система знає де початок евенту де кінець.
Потім. Коли ви виконуєте експорт файлів - чому вони різного обсягу?) Це система експортує готові файли? А ні- бо ми ж зберігаємо ВЕСЬ трафік, у якісь файли, а потім по таблиці бігаємо шукаємо секунди. А для експорту ми створюємо нові файли, без мусору-"кадрів пустишек"?) 
Ріллі?)
А коли поставили новий диск і через добу бачимо використано стільки, вільно стільки - вважаєте це не реальні цифри?) Там збережені тільки евенти чи евенти +кадри пустишки?)))))
Та ну)

Трохи вище є документ про те як працює Hikvision FS на якихось Hikvision DVR. Звісно, нічого кращого знайти не вдалося на цей час.

З того документу видно, що весь простір розділено на кілька частин, в яких окремо зберігаються відео дані та якісь додаткові маркери й ще щось. В якомусь сенсі це схоже на загальний підхід у інших файлових систем теж. Коли наприклад, десь зберігаються таблиці ACL, які відповідають за права доступу до якихось даних.

FS має можливість дуже швидко без фактично участі HDD маркувати якісь LBA як вільні й далі механізми TRIM про це повідомлять HDD в якомусь паралельному потоці зі своїми іншими пріоритетами. Все що стосується підрахунку зайнятого місця або вільного місця - це функції FS, таблиця якої може знаходиться в RAM, тоді ці операції надшвидкі. До речі, деякі HDD мають як cache з RAM, так й з non-volatile SLC, а це в якомусь сенсі як прискорює роботу з формування стрічок SMR, так й є деяким захистом від втрат даних (в цьому випадку мова про SLC).

 

Підсумую, окремо є маркований контейнер з даними, окремо існують будь-які додаткові маркери, які описуюсь контейнер, тому й пошук швидкий, тому що пошук виконується серед маркерів (які б ті не були), а не перечитуються всі блоки в самому контейнері.

[Mr. D]

12.01.2024 в 01:10, uafisher сказав:

Та я ж вище не просто так згадував, що буфер 256 мбіт на ХДД заб'ється миттєво)
У Хіка по пам'яті 60 сек можна точно, колеги нехай поправлять, перевіряти зараз облом). Берем 4-5, ок 4,5 мбітс трафік*60 сек*64 канали (допустима виробником кількість каналів на 1 ХДД, таких моделей багато). Отримуємо 2 160 Мб, що у 8 разів більше за ВЕСЬ кеш ХДД. Так є диски з 64 мб...

Чому це не RAM? В мене є сумніви щодо 512 KiB/s з кожного каналу, але можливо й так.

В будь-якому випадку 2160 MiB - це всього 2 GiB. 2 GiB RAM'а - це дуже незначне значення на сьогодні.
До речі, швидкості HDD обмежені, й це стосується як CMR, так й SMR, внутрішні швидкості запису значно менші, ніж швидкості останніх версій\ревізій SATA, які вже років 10 не оновлювались.

Мені як побутовому користувачу NVR важко уявити NVR систему лише з одним HDD, який навантажено 64 камерами відеоспостереження. На мою думку, це дуже ненадійно.

12.01.2024 в 01:10, uafisher сказав:

От дякую, ну хоч зараз буду знати що це таке) А я думав то годинник!

Знову ж для мене, як побутового користувача, дивно чути від спеціалістів, що ті не орієнтуються на захисні механізми, які розроблені виробниками саме для того, щоб попередити втрату даних. Всім вже давно відомо, що відновлення даних на HDD набагато дорожче, ніж використання кількох HDD одночасно в якомусь масиві. Впевнений, що всі побутові користувачі це вже давно зрозуміли. Чому це ще не так у NVR системах - це дивно.

 

12.01.2024 в 01:10, uafisher сказав:

Це ви так вирішили? Ви праві! Ну певно, більше скажу - Ланос, Ф1 та Джип вони теж в механічній частині схожі, мають певні спільні риси та принцип дії,  аналогічні механізми, схожі елементи керування, використовують схоже пальне та навіть мають однакову кількість колес! А кольору у світі не існує взагалі!)

Ходимо по колу, на мою думку.

Є виробник, який знає всі тонкощі процесу. Маркетологи виробника розділяють пристрої виробника на категорії. Кількість показників, за якими відбувається класифікація обмежена (існує кілька механічних рішень, кілька схемотехнічних рішень й кілька програмних рішень, які й комбінуються).

Далі з'являється інтегратор, який не знає нічого з технічної частини ні процесу виробництва, ні програмної частини, а лише працює з маркетинговими матеріалами виробника, які на цьому етапі якось класифіковані маркетологами.

Кінцевий користувач купує рішення, яке на базі маркетингових матеріалів або зручних кошторисів зібрав інтегратор.

Ще можливо додати сервіс або support, а також деякий TTL кожного пристрою, що існує в нормальних сучасних обчислювальних системах.

Якщо виробник явно не вказав, що SMR не може бути використаним для систем відеоспостереження, я, як користувач не розумію, чому інтегратор проти цього. Навіть більше, намагаючись вивчити питання не знайшов жодного цьому підтвердження.

Змінено 20 січня користувачем Mr. D

[uafisher]

22 часа назад, Mr. D сказал:

Підсумую, окремо є маркований контейнер з даними, окремо існують будь-які додаткові маркери, які описуюсь контейнер, тому й пошук швидкий, тому що пошук виконується серед маркерів (які б ті не були), а не перечитуються всі блоки в самому контейнері.

Це все зрозуміло і можливо так і є - тільки що ми робимо з предзаписом?))) Схожи немає відповіді, якщо ми не погодимось про модифікацію файла. До речі така завзятість (не припускати цей факт) немає підстав, окрім захисту власної позиції. Це не продуктивно.

22 часа назад, Mr. D сказал:

Чому це не RAM? В мене є сумніви щодо 512 KiB/s з кожного каналу, але можливо й так.
В будь-якому випадку 2160 MiB - це всього 2 GiB. 2 GiB RAM'а - це дуже незначне значення на сьогодні.

Тому що виробник встановлює рам 64 або 256 мб на більшості моделей до 8-10 тб. Здається максимум бачив на 512 мб, на великих дисках. Маєте ХДД з кешем 2 Тб - то покажіть! Можемо?)
І 512 кб/с з кожного каналу це не те, щоб можливо - це реальність і не максимальне значення. Це буде Н.265 з 8Мп або Н.264 о 4Мп камери, нормальні значення.
Тому у будь якому випадку 2160 мб раму не існує в диску який стоїть у НВРі. І відповідно наявного кешу 64 чи 256 не вистачає під ваш сценарій. А під мій - немає протирічь.

22 часа назад, Mr. D сказал:

Знову ж для мене, як побутового користувача, дивно чути від спеціалістів, що ті не орієнтуються на захисні механізми, .... Впевнений, що всі побутові користувачі це вже давно зрозуміли. Чому це ще не так у NVR системах - це дивно.

Вибачте ви з якої планети?) Ви як користувач від яких спеціалістів чули що вони (спеціалісти) не орієнтуються на захисні механізми?) Читайте уважно, що ті спеціалісти кажуть-я казав що "не можу" змусити декілька клієнтів змінити старі масиви ХДД, мабуть бо поки грім не гряне мужик.. До речі можу дати номер картки якщо є бажання за власний кошт замінити їм диски. Немає такого бажання? У мене чомусь також.
І мені наприклад, як спеціалісту практику, дивно чути від побутового користувача-теоретика, до того не дуже обізнаного у питанні, що він не буде орієнтуватись на захисні механізми, які створили виробники ХДД - бо він (користувач) вважає це маркетингом, хоча у нього відсутні достатні практичні та теоретичні знання і про властивості і про режим роботи ХДД/НВР. Бо якщо ви використовуєте звичайні диски у НВРі - ви нехтуєте захисними механізмами, які створив виробник.
Як то так)
 

22 часа назад, Mr. D сказал:

Є виробник, який знає всі тонкощі процесу. Маркетологи виробника розділяють пристрої виробника на категорії. Кількість показників, за якими відбувається класифікація обмежена (існує кілька механічних рішень, кілька схемотехнічних рішень й кілька програмних рішень, які й комбінуються).
Далі з'являється інтегратор, який не знає нічого з технічної частини ні процесу виробництва, ні програмної частини, а лише працює з маркетинговими матеріалами виробника, які на цьому етапі якось класифіковані маркетологами.
Кінцевий користувач купує рішення, яке на базі маркетингових матеріалів або зручних кошторисів зібрав інтегратор.

 ))) Ох, ви забули вказати користувача, які без руля, але це не помічає), І про ХДД він вважає це все маркетингом, а в іншій темі про Рукус вважає суцільною правдою запевнення виробника про 4000 варіантів положень антенної решітки і як це сильно впливає на якість сигналу))) Хоча і там йому кажуть як воно є у житті - але ж ми не шукаємо легких стежок, розумію, поважаю)
Взагалі у мене одно питання. Мені очевидна абсолютна нелогічність продавати один товар, штучно розділивши його на 2, якщо ціна не відрізняється. Бо у нас зростає витрати на все, у т.ч. маркетинг та логістіку. От вам скрін з Розетки - диски ВД, один під відео другий під шо попало, ціна однакова. Короче теорія заговору у вас цікава, прикро тільки не підтверджується)

22 часа назад, Mr. D сказал:

Якщо виробник явно не вказав, що SMR не може бути використаним для систем відеоспостереження, я, як користувач не розумію, чому інтегратор проти цього. Навіть більше, намагаючись вивчити питання не знайшов жодного цьому підтвердження.

Ви про мене?) Ми наче це проходили

В 10.01.2024 в 18:31, uafisher сказал:

Ви уважно читаєте про що я пишу? Де хоть раз я вказав, що СМР не використовується у таких дисках? Чи я казав, що про це стверджує виробник? Більше того - я чітко знаю, що Сігейт у лінійці для відео використовує обидва типи - і чесно зазначає де який. ... І ви також все - СМР чи ЦМР. Я не звожу тільки до цього, більше того - думаю це не головне....

Отже, було цікаво, але досить, аргументи не сприйняли/не переконали вас - ок, удачі! 

Змінено 21 січня користувачем uafisher

[Mr. D]

  

32 хвилини тому, uafisher сказав:

Це все зрозуміло і можливо так і є - тільки що ми робимо з предзаписом?))) Схожи немає відповіді, якщо ми не погодимось про модифікацію файла. До речі така завзятість (не припускати цей факт) немає підстав, окрім захисту власної позиції. Це не продуктивно.

Мова про Main Memory в архітектурі NVR, які, на мою думку, є системами або x86-64 архітектури, або ARM архітектури.
Скільки Main RAM в NVR?

32 хвилини тому, uafisher сказав:

Тому що виробник встановлює рам 64 або 256 мб на більшості моделей до 8-10 тб. Здається максимум бачив на 512 мб, на великих дисках. Маєте ХДД з кешем 2 Тб - то покажіть! Можемо?)

Ні, не маю.
Але знаю, що буває cache як у вигляді масивів конденсаторів (RAM) так й транзисторів (SLC) в схемах керування HDD, що дає можливість маючи достатньо обчислювальних можливостей швидко формувати SMR bands.

Загалом мова була про те, що відео буфер на 60 секунд можливо розмістити в Main Memory, а не в cache HDD, де немає можливості контролювати дані з host'а у зв'язку з блоковою архітектурою взаємодії storage host'а та storage device'а.

32 хвилини тому, uafisher сказав:

Рукус вважає суцільною правдою запевнення виробника про 4000 варіантів положень антенної решітки

Такого типу технологію вже бачив в роботі. Й мене, як побутового користувача, це, дійсно здивувало.
Вважаю, що Ruckus працює за дещо схожим алгоритмом, як антени Starlink.
Що саме не вірно зазначено в обговорені антен та пристроїв зв'язку?

Для читачів цієї теми в, мабуть, десятий раз додам, що я нічого не продаю й не рекламую Ruckus. Але, маю надію, спробую особисто обладнання в роботі.

Змінено 21 січня користувачем Mr. D

[k-master]

22.01.2024 в 00:29, Mr. D сказав:

Загалом мова була про те, що відео буфер на 60 секунд можливо розмістити в Main Memory, а не в cache HDD, де немає можливості контролювати дані з host'а у зв'язку з блоковою архітектурою взаємодії storage host'а та storage device'а

Хтось мені може пояснити навіщо така складність, що ще й вимагає ставити більше пам'яті? Пишемо все на диск, коли з'являється евент - помічаємо область пам'яті на диску як данні. Ну наприклад - якщо вам треба 30 секунд предзапису - виділяємо кусок диска на 30 секунд та по колу туди пишемо потік, коли з'являється евент поруч пишемо ще  скільки треба евента та виділяємо новий блок на диску. Кеш диска диск не використовує для запису бо він ніколи не знає коли вимкнуть живлення. У нормальних системах де є кеш запису завжди є батарейка, якщо живлення зникає то після відновлення усі дані з кеша записують на диск. Використовувати пам'ять для предзапису теоретично можливо, але дорого та й все ускладнює - під час евента треба як писати потік на диск так й скидати туди буфер, що при кількох одночасних евентах дуже знижує кількість камер що підтримуються бо складно продати реестратор на 16 камер котрий одночасно зможе писати евенти з 8-ми. 

[Mr. D]

2 години тому, k-master сказав:

Хтось мені може пояснити навіщо така складність, що ще й вимагає ставити більше пам'яті? Пишемо все на диск, коли з'являється евент - помічаємо область пам'яті на диску як данні. Ну наприклад - якщо вам треба 30 секунд предзапису - виділяємо кусок диска на 30 секунд та по колу туди пишемо потік, коли з'являється евент поруч пишемо ще  скільки треба евента та виділяємо новий блок на диску. Кеш диска диск не використовує для запису бо він ніколи не знає коли вимкнуть живлення. У нормальних системах де є кеш запису завжди є батарейка, якщо живлення зникає то після відновлення усі дані з кеша записують на диск. Використовувати пам'ять для предзапису теоретично можливо, але дорого та й все ускладнює - під час евента треба як писати потік на диск так й скидати туди буфер, що при кількох одночасних евентах дуже знижує кількість камер що підтримуються бо складно продати реестратор на 16 камер котрий одночасно зможе писати евенти з 8-ми. 

В якомусь сенсі замість батарейки можливо використати швидкий SLC cache, запис в який буде підтвердженням, що дані з HDD не зникнуть. Host в будь-якому випадку отримує підтвердження, що блок збережено.

В будь-якому випадку RAM надшвидкий й не потребує багато рухів, тобто це буде дуже швидко працювати. Вважаю, що SMR у разі запису по колу просто буде логічно корегувати фізичне розташування даних змінюючи LBA-адреси поступово. Та загалом можу погодитися, що умовний запис по колу працював би.

Загалом, на мою думку, оптимізація операцій потрібна, це все ж й економія енергоспоживання (системи працюють 24/7). Але виробники, схоже, дещо обмежують надання детальної інформації як й що працює. Все ж деяке наслідування технології відбувається, та й інтерфейси відкриті та відомі всі команди. Далі визначається деяка неявна поведінка. Цікава сфера діяльності, але зрозуміло, що цей кваліфікований час, за який хтось сплачує.

У китайських компаній є традиційна проблема з якістю програмного забезпечення, але зараз всі компанії намагаються робите все занадто швидко, тому й у грандів з'являється щось, що недопрацьовано.

Змінено 23 січня користувачем Mr. D

[Фрай]

Хтось може підказати чи треба іноді давати перепочинок відеореєстратору?

Наприклад, я весь день планую бути дома і не маю потреби у відеонагляді тож вимикаю,

але чи дає це щось корисного для подовження терміну служби чи ще що?

[Enot123h]

10 минут назад, Фрай сказал:

Хтось може підказати чи треба іноді давати перепочинок відеореєстратору?

Наприклад, я весь день планую бути дома і не маю потреби у відеонагляді тож вимикаю,

але чи дає це щось корисного для подовження терміну служби чи ще що?

Жорсткому диску такий перепочинок точно не потрібен. У серверах навіть звичайні диски живуть довше, ніж у компах які кожен день вимикають. Не треба його вимушувати голови зайвий раз паркувати.

Коли дивлюсь SMART, велика кількість паркувань напружує більше ніж величезна напрацьовка по годинах.

Змінено 28 січня користувачем Enot123h

[Фрай]

Ви побачили саме те, що я мав на увазі задаючи питання, бо розумію, що перепочинок має бути корисним, але на який час?

Тому що, як ви правильно сказали, кожен старт потребує певних «зайвих рухів» тому ж вінчестеру, а я турбуюсь саме за них.

 

Змінено 28 січня користувачем Фрай

[Mr. D]

  

1 годину тому, Фрай сказав:

Ви побачили саме те, що я мав на увазі задаючи питання, бо розумію, що перепочинок має бути корисним, але на який час?

Тому що, як ви правильно сказали, кожен старт потребує певних «зайвих рухів» тому ж вінчестеру, а я турбуюсь саме за них.

 

Краще навпаки мати резервну систему живлення.

Стабільне електропостачання й охолодження - це найважливіші критерії, які стосуються будь-якої мікроелектроніки. )

Хоча якщо сильно заморозити HDD теж можлива втрата доступу до даних.

Змінено 28 січня користувачем Mr. D

[John Doe]

В 28.01.2024 в 15:14, Фрай сказал:

Хтось може підказати чи треба іноді давати перепочинок відеореєстратору?

Наприклад, я весь день планую бути дома і не маю потреби у відеонагляді тож вимикаю,

але чи дає це щось корисного для подовження терміну служби чи ще що?

Регистраторы расчитаны на 24*7*365 работу.

На то они и "регистраторы"

Змінено 8 лютого користувачем John Doe

[BAV_Lug]

Что за бред тут развели с циклической записью и ожиданием эвента ))

Никогда регик не будет писать на диск, до наступления этого самого эвента. А те секунды до эвента, которые можно сохранять - они хрянятся в оперативке самого регика.

 

Проверить это легко - почти на всех региках есть индикация работы с дисковым массивом.

Змінено 9 березня користувачем BAV_Lug

[Фрай]

08.02.2024 в 15:58, John Doe сказав:

28.01.2024 в 15:14, Фрай сказав:

Хтось може підказати чи треба іноді давати перепочинок відеореєстратору?

Наприклад, я весь день планую бути дома і не маю потреби у відеонагляді тож вимикаю,

але чи дає це щось корисного для подовження терміну служби чи ще що?

Регистраторы расчитаны на 24*7*365 работу. На то они и "регистраторы"

Я ж не питав хто на що розрахований, тим паче, що все має свій ресурс, питав чи не краще буде давати перепочинок?

[uafisher]

6 часов назад, BAV_Lug сказал:

Что за бред тут развели с циклической записью и ожиданием эвента ))

Никогда регик не будет писать на диск, до наступления этого самого эвента. А те секунды до эвента, которые можно сохранять - они хрянятся в оперативке самого регика.

Проверить это легко - почти на всех региках есть индикация работы с дисковым массивом.

Настолько серьёзное заявление, что даже нет желания приводить контраргументы и пытаться предложить вам переосмыслить изложенное разными людьми выше. 
Спасибо что посетили наш форум)))

[Leader9]

В 09.03.2024 в 18:37, Фрай сказал:

Я ж не питав хто на що розрахований, тим паче, що все має свій ресурс, питав чи не краще буде давати перепочинок?

Краще забезпечте стабільне живлення апаратурі і умови роботи (температура, вологість) і хай працює. Кожний старт здоров'я не добавляє. Нижче 15 градусів шкодить механіці, вище 30-40 ще й електроніці...

Змінено 11 березня користувачем Leader9

[Фрай]

Зрозуміло.

Ще питання до фахівців, відрубились пару камер, грішу на контакт, чистка за допомогою ведешки для контактів нічого не дала.

Взагалі не рекомендую купувати це лайно, там написано, що не залишає слідів і це правда, жодного сліду так наче й не чистив. ((

Що порекомендуєте ви?

[unreal1975]

2 часа назад, Фрай сказал:

Зрозуміло.

Ще питання до фахівців, відрубились пару камер, грішу на контакт, чистка за допомогою ведешки для контактів нічого не дала.

Взагалі не рекомендую купувати це лайно, там написано, що не залишає слідів і це правда, жодного сліду так наче й не чистив. ((

Що порекомендуєте ви?

яка модель камер?

[Фрай]

Всі Хіквіжн, ці поряд стоять,

 

вже перевірив, зняв одну, поганий контакт, окисли на них,

 

як міг зачистив і працює, але так важко колупати не знімаючи.

це були додаткові тимчасові камери під час війни і тому зʼєднувальні колодки не були захищені і хоч вони і під дашком, але ж волога та пилюка роблять своє.