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

[Mr. D]

13 хвилин тому, standov сказав:

Все що ви написали це приклад того що я писав вище про "теоретично" та блоковий запис, у випадку з доступом на рівні фс це неможливо, бо там є досить обмежений набір команд який абстрагований від геометрії і алгоритмів її заповнення, в цьому суть файлової системи - ви не думаєте про сектори, за вас думає драйвер фс.

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

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

ПС. В мене відчуття що ви не до кінця розумієте в принцип роботи smr запису

Поки я бачу якісь невідповідності, які й хотів би зрозуміти.

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

[Mr. D]

39 хвилин тому, standov сказав:

Все що ви написали це приклад того що я писав вище про "теоретично" та блоковий запис, у випадку з доступом на рівні фс це неможливо, бо там є досить обмежений набір команд який абстрагований від геометрії і алгоритмів її заповнення, в цьому суть файлової системи - ви не думаєте про сектори, за вас думає драйвер фс.

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

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

ПС. В мене відчуття що ви не до кінця розумієте в принцип роботи smr запису

Програма керування HDD нічого не знає про файлову систему, але знає якими секторами (яка кількість загалом) оперує host.
Драйвер файлової системи нічого не знає про фізичну структуру SMR HDD, скільки стрічок існує, на якій пластині знаходиться деякий довільний сектор.
Все вірно?

Тоді питання - програма керування HDD знає який сектор вільний або зайнятий? Драйвер файлової системи повідомляє про це HDD?

Змінено 29 грудня 2023 користувачем Mr. D

[Mr. D]

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

Програма керування HDD нічого не знає про файлову систему, але знає якими секторами (яка кількість загалом) оперує host.
Драйвер файлової системи нічого не знає про фізичну структуру SMR HDD, скільки стрічок існує, на якій пластині знаходиться деякий довільний сектор.
Все вірно?

Тоді питання - програма керування HDD знає який сектор вільний або зайнятий? Драйвер файлової системи повідомляє про це HDD?

Й ось відповідь

"...TRIM/UNMAP is supported for external hard drives with SMR (Shingled Magnetic Recording) to improve Write performance over time. One of the shingled write benefits is that all physical sectors are written sequentially in a direction radially and are only rewritten after a wrap-around. Rewriting a previously written LBA (Logical Block Addressing) will cause the previous write to be marked invalid and the LBA will be written to the next sequential physical sector. The TRIM/UNMAP enables the OS to inform the drive which blocks are no longer considered to be in use and can be reclaimed internally by the HDD to ensure that later write operations perform at full speed..."

support-en.wd.com/app/answers/detailweb/a_id/25185#subject3

 

Тому це проблема NVR, якщо той або його драйвер\операційна система не знає, що робити з TRIM.

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

 

Загалом дякую Вам за діалог на тему CMR та SMR HDD.

 

Маю ось такий NVR Hikvision DS-7616NI-K2/16P та ніяк не можу зрозуміти, яка файлова система розгорнута на HDD. Припускаю, Hikvision щось придумав своє.

Змінено 29 грудня 2023 користувачем Mr. D

[standov]

14 часов назад, Mr. D сказал:

Драйвер файлової системи повідомляє про це HDD?

Ні, юзерлевел драйвер на рівні ос працює на рівні користувацьких команд (записати, прочитати, видалити). Останнім часом додалася команда трім як специфічна для сдд. Є у драйвера сервісний рівень доступу для форматування, перевірки поверхні, створення фс, але це окремий рівень який вже не знає про корисну інформацію (там натурально 2 стани - шось записано або нічого не записано, відповідно до таблиці). Теоретично два рівні можуть використовуватися одночасно (наприклад так роблять усілякі клонувальники) але для рівня аплікейшена нвр це точно не використовується бо не має сенсу. 

14 часов назад, Mr. D сказал:

Припускаю, Hikvision щось придумав своє

Майже напевно там якийсь ембедед лінукс з якимсь ext3 фс, бо це просто, надійно, безкоштовно, зрозуміло.

Змінено 30 грудня 2023 користувачем standov

[k-master]

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

Майже напевно там якийсь ембедед лінукс з якимсь ext3 фс, бо це просто, надійно, безкоштовно, зрозуміло.

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

[standov]

2 часа назад, k-master сказал:

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

Ну це досить суперечливе питання, але якщо вигадали то і ок ) в убікуті наче як ext але треба ще раз подивитися, ніколи особливо не цікавився 

[standov]

2 часа назад, k-master сказал:

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

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

[Mr. D]

12 годин тому, standov сказав:

Ні, юзерлевел драйвер на рівні ос працює на рівні користувацьких команд (записати, прочитати, видалити). Останнім часом додалася команда трім як специфічна для сдд. Є у драйвера сервісний рівень доступу для форматування, перевірки поверхні, створення фс, але це окремий рівень який вже не знає про корисну інформацію (там натурально 2 стани - шось записано або нічого не записано, відповідно до таблиці). Теоретично два рівні можуть використовуватися одночасно (наприклад так роблять усілякі клонувальники) але для рівня аплікейшена нвр це точно не використовується бо не має сенсу. 

Майже напевно там якийсь ембедед лінукс з якимсь ext3 фс, бо це просто, надійно, безкоштовно, зрозуміло.

Що ж цікава тема.

Тоді продовжимо.

Block device - це як HDD, так й SSD, які під'єднані до комп'ютера в більшості випадків. Операційна система за допомогою або свого kernel або якихось додаткових програм працює з HDD та SSD використовуючи LBA, тобто просто вказуючи які блоки LBA треба прочитати, а які треба записати. Напишу ще раз, що ні HDD, ні SSD нічого не знає про файлову систему, яку використовує операційна система або інша програма, яка працює з HDD\SSD як з block device'ом. Мені здається, з цим вже всі погодились в цій темі.

Які є прикладі file device'ів або file інтерфейсів. Це NFS різних видів, SMB різних видів, можливо, S3, також Apple щось своє має на цей рахунок. Й ось це називають file-інтерфейсами. Але до теми CMR HDD та SMR HDD це не має відношення, очевидно, що iSCSI - це block over IP.

Далі про TRIM. Це команда, яку застосовує host для того, щоб повідомити програму керування HDD або SSD, а фактично block device, про те що деякий LBA range вже не потрібен операційній системі або, скажімо, host'у.

Навіщо виробники додали таку функцію?

Це пов'язано з тим, як саме працює пристрій зберігання типу NAND (саме цей вид storage device'ів частіше за все називають SSD, але ж це може бути й NOR). NAND технологічно має можливість записати одночасно тільки відносно великий block, а це значить у разі модифікації лише одного біта в блоці потрібно весь блок прочитати, модифікувати біт й далі записати. Дещо довго, блоків багато, не дуже ефективно.

Дуже зручно коли транслятор пристрою збереження даних все ж додатково знає, які логічні LBAs вже непотрібні, тоді й оптимізувати\дефрагментувати дані буде дещо ефективніше, чим програма керування SSD й займається "в вільний від роботи час".

Продовжуємо.

А чи не схоже технологічне обмеження SSD на технологічне обмеження SMR HDD, які мають замість блоків великі стрічки? Так, це і є те ж саме фактично. Тому SMR HDD розуміють TRIM, який допомагає оптимізувати запис, який є технологічним обмеженням технології SMR (й зовсім не потрібно на цьому етапі розуміти, що track'и запису дещо перекриваються, точніше written track та read track мають різну ширину).

Тому SMR HDD (програма керування таким HDD) фактично знає які блоки не потрібні, далі в cache збирається нова стрічка й записується відносно швидко. Й у разі NVR цього достатньо для нормальної роботи NVR.

Але давайте для прикладу візьмемо NAS. NAS з одного боку працює з block-пристроями (мені, наприклад, зручно працювати з ZFS), а з іншого боку (з боку користувачів) працює як "файл" (SMB Opportunistic Locks обговорювати не будемо).

 

Тому я роблю висновок, що немає принципової різниці для NVR HDD має CMR або SMR write technology.

Для ще більшої страховки можливо використовувати на SMR HDD не 100% простору, а менше, щоб була можливість ефектично формувати стрічки. Але це лише моя здогатка, яка в чомусь походить від принципу роботи деяких SSD.

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

 

Тепер про Hikvision.

Немає в мене підтвердження, яка файлова система розгорнута на HDD. Хоч я й можу під'єднатися до Hikvision через SSH, там мене зустрічає або якийсь BusyBox, або psh або ще щось. Й далі ходу немає. Тому як саме Hikvision працює не зрозуміло. Але в будь-якому випадку, навіть ОС Hikvision працює через LBA та, припускаю, підтримує ATA TRIM.

Змінено 31 грудня 2023 користувачем Mr. D

[Mr. D]

33 хвилини тому, standov сказав:

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

VMware вигадали VMFS, яка достатньо ефективна і є невід'ємною частиною інфраструктури VMware.
Якщо є ресурси, вважаю, є сенс оптимізувати файлову систему під потреби.

Відновлення даних с кожним роком стає все складнішим й складнішим. Та вже деякий час не має ніякого сенсу на фоні ціни одного умовного TiB.

Змінено 31 грудня 2023 користувачем Mr. D

[Mr. D]

До речі, про які швидкості запису йде мова?

10 - 20 MiB/s? SMR HDD ще поспати встигне в такому режимі. )

Змінено 31 грудня 2023 користувачем Mr. D

[standov]

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

[Mr. D]

3 години тому, standov сказав:

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

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

Але й знання про те, що SMR записує доріжки так, що ті доріжки на 20 - 25% накладаються - це і є теоретична інформація, яка не дає ніякої відповіді на питання, чому SMR - це погано.

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

Деякі особливості SMR, звісно, існують й виглядають як зупинка SMR у вигляді відсутності підтверджень швидкого запису на деякий період. Тоді можливо в тому ж NVR перевірити SMR HDD, якщо всі дані по колу будуть перезаписані рази 3 - 4 та нічого не буде втрачено, то SMR HDD працює й встигає всі блоки оптимізувати та дефрагментувати.

Колись таке ж відношення було й до SSD, але наразі будь-який сучасний комп'ютер працює з SSD.

Та все одно користувач має можливість впливати на поведінку HDD - вказуючи деякі параметри файлової системи, налаштовуючи розмір файлів, які записує NVR, тому в цьому обговоренні достатньо багато практики.

 

Наведу практичний приклад.

Мій побутовий комп'ютер за деякий час прочитав 275 TiB та записав 176 TiB даних на свій block-device (це саме щось типу total RAW data, яке було пораховано засобами ОС). Ось такий практичний вимір. Співвідношення 61/39.

 

Тому подальша практика - це визначення швидкості запису, яка потрібна NVR. Думаю, що це не дуже багато в побутовому NVR. Все ж SMR мають великі cache'и та достатньо швидкі процесори.

Змінено 31 грудня 2023 користувачем Mr. D

[uafisher]

В 29.12.2023 в 11:51, Mr. D сказал:

Якщо NVR записав стрічку 256 MiB, навіщо протягом наступної хвилини NVR модифікує цю стрічку?

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

Я не збираюсь роздмухувати цей теоретичний диспут, трохи відірваний від практики. І я точно не фахівець у файлових системах, і зовсім не планую їм стати.
Але чому ви вирішили що нвр лише видаляє файл чи записує?  У тому сенсі, чи запис файла відбувається як одна операція?
Моя думка полягає у тому, що як мінімум при ввімкненому пред запису нвр створює файл та потім його модифікує. Шляхом накачування його відеорядом, який НВР видаляє при відсутності евентів-але зберігаючи відеоряд при евентах. Також цікаво що евентів може бути більше одного на кожній камері...
Кешу навіть у 256 Мб не вистачить досить швидко, відповідно ці "пусті" кадри без подій нвр має фізично записувати на диск, майже "моментально" затираючи їх новими пустишками, аж до настання події і "старту" запису. Згодом запис у цей файл припиняється.

[standov]

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

[Mr. D]

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

Я не збираюсь роздмухувати цей теоретичний диспут

Навіщо Ви тоді питаєте?

  

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

Але чому ви вирішили що нвр лише видаляє файл чи записує?  У тому сенсі, чи запис файла відбувається як одна операція?

Тому що ваші міркування на рівні користувача, а не на рівні block-пристрою зберігання даних

  

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

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

Яке відношення мають events до запису відеоданих?

  

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

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

Яка швидкість запису на HDD потрібна NVR?

 

Є LBA, є транслятор в HDD. Тільки HDD знає, де саме фізично знаходяться якісь сектори. Користувач не має можливості записати дані фізично в будь-яке місце на поверхні пластин.

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

Нагадаю, що HDD не оперує файлами або директоріями.

[standov]

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

Нагадаю, що HDD не оперує файлами або директоріями.

ними оперує драйвер фс але нашо я повторююсь я прям хз ))  якийсь вже академічний експеримент чим то може закінчитися 

[Mr. D]

17 хвилин тому, standov сказав:

ними оперує драйвер фс але нашо я повторююсь я прям хз ))  якийсь вже академічний експеримент чим то може закінчитися 

Нагадаю, що програма керування HDD працює з хостом в контексті LBA.

HDD нічого не знає про те, яка саме файлова система використовується ОС або користувачем.

Тому в деяких випадках користувач для портативних NAND'ів може застосувати спеціалізовані файлові системи, але все ще можливо використати традиційні файлові системи й на портативних NAND'ах.

[uafisher]

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

Тому що ваші міркування на рівні користувача, а не на рівні block-пристрою зберігання даних

Звісно. Я здогадуюсь, що ваші знання також на рівні людини, а не пристрою)

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

Яке відношення мають events до запису відеоданих? 

Пряме

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

Яка швидкість запису на HDD потрібна NVR?

Відповідь очевидна ( по простому (бітрейт 1 камери Х на кіл-ть камер)+У мб "службового трафіку" на усякі маркери, тут не впевнений).
Але я зовсім не про це, перечитайте уважніше.

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

Є LBA, є транслятор в HDD. Тільки HDD знає, де саме фізично знаходяться якісь сектори. Користувач не має можливості записати дані фізично в будь-яке місце на поверхні пластин.

Безумовно це дуже цікаво. Але нащо воно нам?) Хтось намагається?)

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

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

Можете стисло викласти ваше уявлення файлових операцій при активованому пред/пост запису на нврі, бажано з підтвердженням?

[Mr. D]

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

Звісно. Я здогадуюсь, що ваші знання також на рівні людини, а не пристрою)

Пряме

Відповідь очевидна ( по простому (бітрейт 1 камери Х на кіл-ть камер)+У мб "службового трафіку" на усякі маркери, тут не впевнений).
Але я зовсім не про це, перечитайте уважніше.

Безумовно це дуже цікаво. Але нащо воно нам?) Хтось намагається?)

Можете стисло викласти ваше уявлення файлових операцій при активованому пред/пост запису на нврі, бажано з підтвердженням?

Будь ласка, ознайомтесь з попередніми відповідями та коментарями та сформулюйте конкретне технічне питання.

На всякий випадок напишу, я нічого не продаю, мені особисто байдуже якого типу HDD Ви використовуєте у своєму NVR або у NVR ваших клієнтів.

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

Буду вдячний побачити коментар про те, як саме я міг бі подивитись яка саме файлова система використовується в Hikvision NVR.

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

[Mr. D]

05.01.2024 в 03:23, uafisher сказав:

ввімкненому пред запису нвр створює файл та потім його модифікує

Що таке створення файлу? Навіщо створювати файл, розмір якого 1 GiB та заповнювати його нерелевантними даними для того, щоб пізніше модифікувати. Чому не можливо додати до 1 сектору, в якому розміщені дані, ще один сектор, коли це знадобиться?

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

[Mr. D]

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

Звісно. Я здогадуюсь, що ваші знання також на рівні людини, а не пристрою)

Пряме

Відповідь очевидна ( по простому (бітрейт 1 камери Х на кіл-ть камер)+У мб "службового трафіку" на усякі маркери, тут не впевнений).
Але я зовсім не про це, перечитайте уважніше.

Безумовно це дуже цікаво. Але нащо воно нам?) Хтось намагається?)

Можете стисло викласти ваше уявлення файлових операцій при активованому пред/пост запису на нврі, бажано з підтвердженням?

Ось, будь ласка, відповідь на ваше питання. Не існує HDD, які так швидко можуть записати дані.

Створення файлу, розмір якого 10 GiB, за 1 секунду.

 

C:\>fsutil fsinfo volumeInfo c:
Volume Name :
Volume Serial Number : 0x72272232
Max Component Length : 255
File System Name : NTFS
Is ReadWrite
Not Thinly-Provisioned
Supports Case-sensitive filenames
Preserves Case of filenames
Supports Unicode in filenames
Preserves & Enforces ACL's
Supports file-based Compression
Supports Disk Quotas
Supports Sparse files
Supports Reparse Points
Returns Handle Close Result Information
Supports POSIX-style Unlink and Rename
Supports Object Identifiers
Supports Encrypted File System
Supports Named Streams
Supports Transactions
Supports Hard Links
Supports Extended Attributes
Supports Open By FileID
Supports USN Journal

C:\>dir /l/o/p | findstr nvr

C:\>echo:| time
The current time is: 21:18:20.78
Enter the new time:

C:\>fsutil file createnew c:\NVR.data 10737418240
File c:\NVR.data is created

C:\>echo:| time
The current time is: 21:18:21.13
Enter the new time:

C:\>dir /l/o/p | findstr nvr
06-Jan-24  21:18    10,737,418,240 nvr.data

 

або

 

[administrator@localhost ~]$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    0     1T  0 disk 
├─sda1        8:1    0     1G  0 part /boot
└─sda2        8:2    0  1023G  0 part 
  ├─rl-root 253:0    0    70G  0 lvm  /
  ├─rl-swap 253:1    0   3.9G  0 lvm  [SWAP]
  └─rl-home 253:2    0 949.1G  0 lvm  /home
sr0          11:0    1  1024M  0 rom  

[administrator@localhost ~]$ findmnt /

TARGET SOURCE              FSTYPE OPTIONS
/      /dev/mapper/rl-root xfs    rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota

[administrator@localhost ~]$ cd /tmp/

[administrator@localhost tmp]$ ls -ahl | grep NVR

[administrator@localhost tmp]$ time fallocate -l 10G NVR.data

real    0m0.002s
user    0m0.001s
sys    0m0.000s

[administrator@localhost tmp]$ ls -ahl | grep NVR
-rw-rw-r--.  1 administrator administrator  10G Jan  6 21:41 NVR.data
 

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

[uafisher]

В 06.01.2024 в 20:23, Mr. D сказал:

Ось, будь ласка, відповідь на ваше питання. Не існує HDD, які так швидко можуть записати дані.

Створення файлу, розмір якого 10 GiB, за 1 секунду.

Ваші навички звісно здатні вразити, шкода не мають жодного відношення до мого питання.
Будь - ласка- прочитайте питання ще раз. Якщо воно не зрозуміло - скажіть, я сформулюю інакше.
Реєстратор Хіквіжен...Пред запис.

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

[uafisher]

В 06.01.2024 в 15:27, Mr. D сказал:

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

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

В 06.01.2024 в 15:27, Mr. D сказал:

Буду вдячний побачити коментар про те, як саме я міг бі подивитись яка саме файлова система використовується в Hikvision NVR.

Певно романтичним особам можна спробувати за роз'ясненням звернутись до виробника. Другий шлях- влаштуватись до нього на роботу) Правда, мабуть, спочатку прийдеться підписати де-які папери, які не дадуть змогу згодом поділитися з нами цими знаннями. Ну хоть ви будете у курсі).

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

[Mr. D]

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

Ваші навички звісно здатні вразити, шкода не мають жодного відношення до мого питання.
Будь - ласка- прочитайте питання ще раз. Якщо воно не зрозуміло - скажіть, я сформулюю інакше.
Реєстратор Хіквіжен...Пред запис.

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

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

Якщо NVR використовує block storage device для зберігання даних, то всі зазначені особливості роботи HDD або навіть SSD все ще застосовуються до цих пристроїв зберігання даних.

Немає іншого методу доступу в HDD окрім LBA (з тих типів HDD, які обговорюються).

[Mr. D]

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

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

Певно романтичним особам можна спробувати за роз'ясненням звернутись до виробника. Другий шлях- влаштуватись до нього на роботу) Правда, мабуть, спочатку прийдеться підписати де-які папери, які не дадуть змогу згодом поділитися з нами цими знаннями. Ну хоть ви будете у курсі).

Вважаю, що з точки зору звичайного побутового NVR немає різниці використовується SMR HDD або CMR HDD.

Поки що не побачив жодного пояснення, чому це не так.

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

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