Когда можно будет забыть о пропадании архивов?

[User13]

Удалено администратором.

[Duser]

Для выявления и устранения ошибок существует бета-тестирование. Вот мне интересно у вас какой штат бета-тестеров? И как долго длится бета-тестирование очередной версии программы перед выпуском в свет? Каковы критерии перевода очередной версии из беты в стабильную?
Стабильных версий ВН - по пальцам пересчитать: 7.3 и 8.4 ВСЁ! Все прочие версии у порядочных релизеров обязаны были бы носить статус беты (а некоторые - даже альфы).
И не надо мне рассказывать о невозможности обнаружить проблему. Моя проблема с софтовым рейдом повторялась стабильно - это означает, что вы могли её увидеть сразу же как только на машине сравнимой мощности (CAB вам в руки) создали бы том такого же размера, запустили на него архивацию и дождались закольцовки. Вы это сделали? Вопрос риторический.
Ныне вам известна проблема с архивацией в актуальной версии вашего ПО (8.9sp1). Архивы пропадают при архивации. Проблема легко повторяется. Она стабильна и не зависит от железа. По-крайней мере у меня проблема повторилась на четырех(!!!) разных машинах.
Где исправления?

Сами подумайте, какая разница для ВН - софтовый рейд или нет? ВН работает с ним через ОС. На софтовом рейде, по Вашим словам, на версии 8.4 не работал архив с размером тома в 2.5 Тб, а на аппаратном с томом в 7 Тб уже "выдавала нечастые сбои". Как же так?

Как же так? Это вы меня спрашиваете?
Это я вас должен спросить!
Как же так - на одном и том же железе, одной и той же оси, на ОДНОМ И ТОМ ЖЕ СОФТОВОМ РЕЙДЕ ваша программа работает с тремя томами 800ГГб и не работает с одним томом 2,5Тб? Причем когда архивация ВН еле шевелится (из-за низкой производительности софт-рейда, как мне тут объясняли), винда копирует с того же рейда на тот же рейд гигабайты вполне себе резво? Видимо это оси всё равно какой рейд, а вот ВН - привередничает. При этом саппорт настоятельно рекомендует махнуть рейд на аппаратный. Решение с разбивкой томов нашел я сам методом научного тыка.
Как же так - по вашей рекомендации сменили рейд на аппаратный (который 7Тб), более того - махнули сервер на куда более мощный, а проблемы с архивом не пропали? Нет архивация пошла, но...как то нестабильно: то функция архивации заглохнет с ошибкой, то кусок архива пропадет...Ну мы то привыкли, но неприятный осадок, знаете ли. Саппорт рекомендует там поднастроить, тут подкрутить - эффект от этих манипуляция нулевой.
Как же так - поставили самую последнюю версию вашей "изо дня в день на пиковых нагрузках" тестируемой программы, а архивы пропадают? Вы вообще понимаете, что значит пропадание архива для системы охранного телевидения? Это ЧП, если не сказать саботаж.
И dll'ки от предыдущего релиза, кстати, решая проблему с пропаданием архива, создают новую проблему - архивация срывается. На моей системе, по-крайней мере. САВ в саппорт отправлен. И...что?

А я ведь при покупке заплатил за ваше ПО всю сумму. И ни один рубль не пропал, заметьте, в отличие от архивов!

[Vibat]

Ради интереса хочу спросить, а разве нельзя обойтись без архивации ? Всё таки это копирование с одного тома на другой том, что только отнимает место на дисках.
Тем более что выявилась (вроде как) такая проблема именно при архивации .
У меня также не всегда всё работает, и не всегда ТП может помочь. Но то что стараются это сделать - несомненно.

[Predator]

Ныне вам известна проблема с архивацией в актуальной версии вашего ПО (8.9sp1). Архивы пропадают при архивации. Проблема легко повторяется. Она стабильна и не зависит от железа. По-крайней мере у меня проблема повторилась на четырех(!!!) разных машинах.
Где исправления?

Исправления Вам были высланы 16.01.2015, сразу после получения от Вас запроса.

Сами подумайте, какая разница для ВН - софтовый рейд или нет? ВН работает с ним через ОС. На софтовом рейде, по Вашим словам, на версии 8.4 не работал архив с размером тома в 2.5 Тб, а на аппаратном с томом в 7 Тб уже "выдавала нечастые сбои". Как же так?

Как же так? Это вы меня спрашиваете?
Это я вас должен спросить!
Как же так - на одном и том же железе, одной и той же оси, на ОДНОМ И ТОМ ЖЕ СОФТОВОМ РЕЙДЕ ваша программа работает с тремя томами 800ГГб и не работает с одним томом 2,5Тб? Причем когда архивация ВН еле шевелится (из-за низкой производительности софт-рейда, как мне тут объясняли), винда копирует с того же рейда на тот же рейд гигабайты вполне себе резво? Видимо это оси всё равно какой рейд, а вот ВН - привередничает. При этом саппорт настоятельно рекомендует махнуть рейд на аппаратный. Решение с разбивкой томов нашел я сам методом научного тыка.

Мне сложно сказать, почему софтовый рейд у Вас не работал корректно с томом на 2.5 Тб, и корректно работал с несколькими томами по 800Мб. Думаю, это связано с особенностью работы софтового рейда и конкретным сочетанием железа с задачами, возложенными на него.
Насчет скорости работы - сравнение Ваше некорректно, поскольку копирование файлов и работа со сложноструктурированной БД - разные вещи.
Мы, оценивая скорость работы подсистемы записи, архивации и восстановления, проводили сравнения с результатами, полученными при тестировании производительности разных дисковых массивов в режимах, схожих с работой архива VideoNet (тестирование проводилось с использованием Intel IO Meter). Заверяю Вас, скорость работы VideoNet c дисковой подсистемой соответствует скорости работы данной подсистемы в соответствующем режиме.

Как же так - по вашей рекомендации сменили рейд на аппаратный (который 7Тб), более того - махнули сервер на куда более мощный, а проблемы с архивом не пропали? Нет архивация пошла, но...как то нестабильно: то функция архивации заглохнет с ошибкой, то кусок архива пропадет...Ну мы то привыкли, но неприятный осадок, знаете ли. Саппорт рекомендует там поднастроить, тут подкрутить - эффект от этих манипуляция нулевой.
Как же так - поставили самую последнюю версию вашей "изо дня в день на пиковых нагрузках" тестируемой программы, а архивы пропадают? Вы вообще понимаете, что значит пропадание архива для системы охранного телевидения? Это ЧП, если не сказать саботаж.

Согласен с Вами, потеря архива - это ЧП. Мы, конечно же, тестируем разные варианты использования - на разном железе, но все равно, предусмотреть все возможные нюансы использования нашего ПО пользователями не можем. Причем, пользователи ПО используют его на всем ассортименте комплектующих имеющихся в продаже. Когда узнаем о проблемах, изучаем в чем особенность применения и находим пути решения, чтобы и в такой ситуации не было потери данных.

[dronas]

Добрый день.

Возможно дело в этом?

http://forum.ixbt.com/topic.cgi?id=11:45424
---------------------
Хочу предостеречь всех владельцев больших HDD. Больших - это больше 2.2TB, т.е. 3TB, 4TB и т.п. Сказанный ниже рецепт в целом годен на все случаи жизни (т.е. даже если у вас не такое железо, но в теории есть шанс встретиться с любым другим железом и подобными глюками с 32-битным ограничением расчета, в т.ч. даже в софте).

Контроллер Marvell 88SE91xx, по крайней мере, с BIOS <= 1.0.0.1031 не поддерживает полноценно диски объемом больше 2.2TB. Его BIOS при каждой перезагрузке по физическому смещению BAA1471E00h на каждый диск прописывает бэкап GPT-таблицы размером в 4060h байт (и тем самым портит ваши данные). Это смещение - граница 746.52Gb (достаточно известная константа) из-за переполнения адресации.
---------------------

[Duser]

Исправления Вам были высланы 16.01.2015, сразу после получения от Вас запроса.

Версии присланных файлов - 8.9.0.ххх, версии файлов в актуальном дистрибутиве с сайта - 8.9.1.ххх. Если это и есть исправления, то несколько странновата нумерация версий, обычно более новый файл имеет и бОльший номер версии.
Ну да не в этом дело. Я то имел ввиду исправление актуальной версии лежащей на сайте. Вы вот тут прям убедительно уверяете меня и аудиторию форума, что по мере сил находите пути решения, максимально быстро стараетесь устранить найденные проблемы...А октябрьская версия с кривым кодом, ведущим к пропаданию данных при архивации, так и висит, хотя исправления у Вас уже имеются. Это как понимать?

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

Понимаете, проблема стабильно проявлялась при одном томе VN размером ~2.5Тб, и вообще не проявлялась при трех томах VN размером ~800Гб, причем и на большом размере тома всё работало до заполнения и начала циклической перезаписи. Все прочие условия были равны в обоих случаях, включая размер логического диска на софтовом рейде, где располагались тома, а также объем архивируемых данных. Разве можно при таких вводных думать, что виновато что-либо кроме криво реализованной работы вашей "сложноструктурированной БД"? Или таки для ОСи есть разница, что там ваша программа делает с файлом (ведь ваш архивный контейнер, является с точки зрения ОСи самым обычным файлом) - пишет новые данные на место нулей (или чем там заполняется в момент создания архивный контейнер), или пишет новые данные на место старых?

А ваши постоянные неуклюжие попытки свалить вину за ваш нерабочий кривой код на железо-ОСь выглядят совсем уж неприлично с некоторых пор. Особенно учитывая список протестированных железок.

Кстати, чего там "сложноструктурировать" то? Двумерный массив "номер_камеры-время_записи"? Тем более, если это "сложноструктурированное" толком не работает? А может ну её на хфик, ту сложную структуру? Писали бы видеофайлы просто в папки с названиями камер, а в качестве метки времени использовали бы атрибут "время создания", устанавливаемый драйвером файловой системы, а? Корейцы из JSTelecom (если не ошибаюсь) так и сделали в своей системе AceCop примерно во времена выхода вашей восьмой версии и при всех минусах AceCop'а я ни разу не слышал о слете архивов на их системе, тогда как у вас проблемы с архивом - добрая традиция.
Ну если не можете нормально реализовать, зачем подставлять конечного пользователя, вы же не утилитку перекодирования продаете, а профессиональную систему БЕЗОПАСНОСТИ?

Понимаете, мне как пользователю, по-большому счету плевать каким образом у вас реализована та или иная функция, сложно- у вас там структурировано или вобще не структурировано, мне главное - чтобы система выполняла поставленные задачи НАДЕЖНО в первую очередь. А коли ваша система БЕЗОПАСНОСТИ не обеспечивает положенной надежности - все ваши объяснения мне мало интересны. По-крайней мере до устранения критических проблем вашего ПО...ну или до возврата уплаченных денег.

Согласен с Вами, потеря архива - это ЧП. Мы, конечно же, тестируем разные варианты использования - на разном железе, но все равно, предусмотреть все возможные нюансы использования нашего ПО пользователями не можем. Причем, пользователи ПО используют его на всем ассортименте комплектующих имеющихся в продаже. Когда узнаем о проблемах, изучаем в чем особенность применения и находим пути решения, чтобы и в такой ситуации не было потери данных.

Ещё раз: проблема с пропаданием архивов при архивации в версии VN8.9sp1 - чисто программная и железо-независимая. Это следует из того факта, что на четырех серверах (три из которых собраны на "протестированном" вами железе) проблема СТАБИЛЬНО проявляется при использовании файлов версии 8.9.1.ххх и НЕ проявляется при использовании файлов версии 8.9.0.ххх.
А ещё из этого факта следует простой вывод, что работу этой версии программы вы в режиме архивации не тестировали.

Ради интереса хочу спросить, а разве нельзя обойтись без архивации ? Всё таки это копирование с одного тома на другой том, что только отнимает место на дисках.

В моем случае преследовались несколько целей - разгрузка оперативных серверов при работе пользователей с архивом и увеличение объема и дополнительное резервирование архивов.

Добрый день.
Возможно дело в этом?
...

Не в этом. На моих серверах не используются диски более 2Тб.

[Vibat]

Проблема пропадания записей возникает при совместной записи в один том обычной записи и записи архивации (определяемой функцией архивации) ?
В таком случае тома можно разделить, те архивировать в специальный отдельный том

[Predator]

Исправления Вам были высланы 16.01.2015, сразу после получения от Вас запроса.

Версии присланных файлов - 8.9.0.ххх, версии файлов в актуальном дистрибутиве с сайта - 8.9.1.ххх. Если это и есть исправления, то несколько странновата нумерация версий, обычно более новый файл имеет и бОльший номер версии.
Ну да не в этом дело. Я то имел ввиду исправление актуальной версии лежащей на сайте. Вы вот тут прям убедительно уверяете меня и аудиторию форума, что по мере сил находите пути решения, максимально быстро стараетесь устранить найденные проблемы...А октябрьская версия с кривым кодом, ведущим к пропаданию данных при архивации, так и висит, хотя исправления у Вас уже имеются. Это как понимать?

Это понимать следует так: мы находим и исправляем ошибки по мере поступления запросов от пользователей. Данные пользователи получают исправления сразу. Разные исправления накапливаются, мы дополнительно проверяем их совместную работу, после чего перевыпускаем билд или дополняем этими исправлениями очередную версию.

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

Понимаете, проблема стабильно проявлялась при одном томе VN размером ~2.5Тб, и вообще не проявлялась при трех томах VN размером ~800Гб, причем и на большом размере тома всё работало до заполнения и начала циклической перезаписи. Все прочие условия были равны в обоих случаях, включая размер логического диска на софтовом рейде, где располагались тома, а также объем архивируемых данных. Разве можно при таких вводных думать, что виновато что-либо кроме криво реализованной работы вашей "сложноструктурированной БД"? Или таки для ОСи есть разница, что там ваша программа делает с файлом (ведь ваш архивный контейнер, является с точки зрения ОСи самым обычным файлом) - пишет новые данные на место нулей (или чем там заполняется в момент создания архивный контейнер), или пишет новые данные на место старых?

Вы писали, что после замены рейда, у Вас та же версия VN работала уже с куда большим томом чем 2.5Тб. Вот так и мы, при тестировании использовали разные рейд-контроллеры, создавали тома разного размера, создавали и отрабатывали разные сценарии работы с архивом и т.д. И у нас поведение системы на момент выпусков VideoNet было корректным. В последствии, получая запросы от пользователей мы повторяем у себя их конфигурации и задачи, изучаем поведение системы и если обнаруживаем ошибки - исправляем их.

А ваши постоянные неуклюжие попытки свалить вину за ваш нерабочий кривой код на железо-ОСь выглядят совсем уж неприлично с некоторых пор. Особенно учитывая список протестированных железок.

Я не сваливаю вину, я пытаюсь до Вас донести, что ошибки есть в любом софте, но их проявление зависит от эксплуатации: сочетания железа, стороннего ПО, задач которые возлагаются на систему.

Кстати, чего там "сложноструктурировать" то? Двумерный массив "номер_камеры-время_записи"? Тем более, если это "сложноструктурированное" толком не работает? А может ну её на хфик, ту сложную структуру? Писали бы видеофайлы просто в папки с названиями камер, а в качестве метки времени использовали бы атрибут "время создания", устанавливаемый драйвером файловой системы, а? Корейцы из JSTelecom (если не ошибаюсь) так и сделали в своей системе AceCop примерно во времена выхода вашей восьмой версии и при всех минусах AceCop'а я ни разу не слышал о слете архивов на их системе, тогда как у вас проблемы с архивом - добрая традиция.

Структура видеоархива, которая опирается на дату и время создания файла, не подходит для системы безопасности. Простота изменения пользователем даты и времени у видеофрагмента - удобный инструмент для подлога, фальсификации и т.д. Кроме того, такая структура архива не позволяет обеспечить необходимое быстродействие. Мы это проходили на VideoNet 7.
Пользователь хочет одновременно с записью воспроизводить синхронно и асинхронно несколько источников, архивировать видеозаписи, просматривать видео по сети, делать экспорт клипов и все одновременно. Уверен, что если Вы попробуете выполнить все те действия с видеоархивом которые Вы делаете на VN, на системах использующих описанную Вами структуру - Вы будете неприятно удивлены - они этого просто не смогут выполнить большую их часть.

[Duser]

Проблема пропадания записей возникает при совместной записи в один том обычной записи и записи архивации (определяемой функцией архивации) ?

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

Это понимать следует так: мы находим и исправляем ошибки по мере поступления запросов от пользователей. Данные пользователи получают исправления сразу. Разные исправления накапливаются, мы дополнительно проверяем их совместную работу, после чего перевыпускаем билд или дополняем этими исправлениями очередную версию.

А в это время пользователи, купившие вашу "систему безопасности номер один" и обновившиеся до последней актуальной версии (89sp1), рискуют потерять архив. Замечательно!

Вы писали, что после замены рейда, у Вас та же версия VN работала уже с куда большим томом чем 2.5Тб.
...

И на куда более мощном железе! Вот этот фактор, видимо, и позволил вашей сложноструктурированной БД более-менее успевать ворочаться на большом томе.

Вот так и мы, при тестировании использовали разные рейд-контроллеры, создавали тома разного размера, создавали и отрабатывали разные сценарии работы с архивом и т.д. И у нас поведение системы на момент выпусков VideoNet было корректным. В последствии, получая запросы от пользователей мы повторяем у себя их конфигурации и задачи, изучаем поведение системы и если обнаруживаем ошибки - исправляем их.

Вся эта лирика мне, как пользователю, мало интересна. Мне важно, чтобы работала именно МОЯ система, а не сотни оттестированных вами, которых я и не видел ни разу.

Я не сваливаю вину, я пытаюсь до Вас донести, что ошибки есть в любом софте, но их проявление зависит от эксплуатации: сочетания железа, стороннего ПО, задач которые возлагаются на систему.

Вот, спасибо вам.
Ну и я, с вашего позволения, попытаюсь донести в свою очередь.
Насколько мне известно, найденные ошибки в любом софте принято классифицировать по степени серьезности, причем наиболее серьезными принято считать ошибки, приводящие к полной или частичной (но существенной) потере функциональности софта, тем более, когда оная потеря потенциально может нанести ущерб пользователю софта. Такие ошибки устраняются в первую очередь и выпускать рабочую версию софта с такими ошибками уважающие себя и своих клиентов разработчики себе не позволяют.
Но бывает и на старуху проруха. Бывает такие серьезные ошибки выявляются в уже зарелизенной версии софта. В таких случаях, если не ошибаюсь, разработчик софта старается устранить сию ошибку максимально быстро и (внимание!!!) старается предупредить пользователей софта об таком своем конфузе, дабы по возможности предотвратить потенциальный урон.
Ну например, ошибка в софте бортового компьютера автомобиля, приводящая к проблемам с кондиционером - несерьезна, а вот если проблемы возможны в тормозной системе или, допустим, в работе подушек безопасности...А теперь представьте, что производители авто с такой ошибкой в программе бортового компьютера, доносят до вас "что ошибки есть в любом софте, но их проявление зависит от эксплуатации". Сомневаюсь, что вы будете достаточно к ним лояльны, особенно если сия ошибка проявится именно в вашем авто. Не дай Бог, конечно.
Серьезность ошибки в вашем софте вами осознается, очевидно. С момента её обнаружения прошло два месяца. Кроме высылки файлов УЖЕ пострадавшим от вашего кривокодия пользователям и попыток донести до меня, что-то ещё сделано, стесняюсь спросить?

Структура видеоархива, которая опирается на дату и время создания файла, не подходит для системы безопасности. Простота изменения пользователем даты и времени у видеофрагмента - удобный инструмент для подлога, фальсификации и т.д.

Есть такая штука - разграничение прав пользователя, большинство файловых систем включая NTFS такую штуку поддерживают. Странно, что мне приходится об этом говорить ведущему инженеру отдела проектных решений.
А при наличии неограниченных прав в системе (читай прав администратора) и ваш сложноструктурированный архив порушить - не проблема. А в последних версиях вашего софта для этого и прав особых не надо, достаточно использовать необходимые для работы VN права на изменение системного времени. Уже обсуждалось.

Кроме того, такая структура архива не позволяет обеспечить необходимое быстродействие. Мы это проходили на VideoNet 7.
Пользователь хочет одновременно с записью воспроизводить синхронно и асинхронно несколько источников, архивировать видеозаписи, просматривать видео по сети, делать экспорт клипов и все одновременно. Уверен, что если Вы попробуете выполнить все те действия с видеоархивом которые Вы делаете на VN, на системах использующих описанную Вами структуру - Вы будете неприятно удивлены - они этого просто не смогут выполнить большую их часть.

И снова вы забываете, что ваши архивы пропадают. И мне, как пользователю, глубоко плевать, насколько быстродействующим был мой ПРОПАВШИЙ архив.
Что же касается низкого быстродействия файловых систем (а хоть и NTFS), которые сами по себе представляют своего рода БД, в сравнении с вашей сложноструктурированной БД - не уверен. Тестировали, говорите? Так выложите методику и результаты тестирования, а потом и поговорим. Особенно интересны таковые тесты на слабых машинах.

Я вообще-то упомянул такой способ хранения видеоархива в качестве не самого лучшего, но наиболее простейшего.
Однако этот способ обеспечит более высокую надежность архива, чем ваше решение. По той простой причине, что разработчики файловых систем просто не могут позволить себе релизить софт с такими серьезнейшими багами, как у вас.

[Vibat]

Проблема пропадания записей возникает при совместной записи в один том обычной записи и записи архивации (определяемой функцией архивации) ?

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

Да никак они не отличаются, кроме как указании пути владельца записи в проигрывателе.
У меня также 8.9 сп.1 на нескольких объектах, пишу в один том том и обычную запись и архивацию ( не скрою, сделал это специально почитав твою тему и пообщавшись с тп ). Каков алгоритм заставить систему так работать ? Ну чтоб записи пропали ? Как это выглядит в проигрывателе ?

[Duser]

Алгоритм простой: делаешь архивацию в том, всё. В проигрывателе это выглядит как отсутствие записей там, где они ранее существовали.

На всех моих серверах стоит Win 2003 Server 32x.
Основной том на оперативных серверах - софтовое зеркало размером ~500Гб, дополнительный том - пустое место на системном диске, размер варьируется. Архивация в дополнительный том с основного приводит к пропаданию архивов в доп.томе.
Tом на сервере архивации - аппаратный райд размером ~7Tб. Архивация в него приводит к пропаданию архивов.

Пропадают архивы только с dll-ками из версии, выложенной на сайте.
Хотя вру, и на 88sp3 такая фигня случалась изредка. На 84 версии такого не было вроде бы.

Не тыкайте с разбегу, не люблю панибратства.

[Predator]

Вы писали, что после замены рейда, у Вас та же версия VN работала уже с куда большим томом чем 2.5Тб.
...

И на куда более мощном железе! Вот этот фактор, видимо, и позволил вашей сложноструктурированной БД более-менее успевать ворочаться на большом томе.

Это не БД, а железо, более-менее успевало справляться с возложенными задачами.

Вот так и мы, при тестировании использовали разные рейд-контроллеры, создавали тома разного размера, создавали и отрабатывали разные сценарии работы с архивом и т.д. И у нас поведение системы на момент выпусков VideoNet было корректным. В последствии, получая запросы от пользователей мы повторяем у себя их конфигурации и задачи, изучаем поведение системы и если обнаруживаем ошибки - исправляем их.

Вся эта лирика мне, как пользователю, мало интересна. Мне важно, чтобы работала именно МОЯ система, а не сотни оттестированных вами, которых я и не видел ни разу.

Все понятно, Вам важно что бы работала Ваша система, Вы обратились в службу техподдержки и она Вам помогла.

Я не сваливаю вину, я пытаюсь до Вас донести, что ошибки есть в любом софте, но их проявление зависит от эксплуатации: сочетания железа, стороннего ПО, задач которые возлагаются на систему.

Вот, спасибо вам.
Ну и я, с вашего позволения, попытаюсь донести в свою очередь.
Насколько мне известно, найденные ошибки в любом софте принято классифицировать по степени серьезности, причем наиболее серьезными принято считать ошибки, приводящие к полной или частичной (но существенной) потере функциональности софта, тем более, когда оная потеря потенциально может нанести ущерб пользователю софта. Такие ошибки устраняются в первую очередь и выпускать рабочую версию софта с такими ошибками уважающие себя и своих клиентов разработчики себе не позволяют.
Но бывает и на старуху проруха. Бывает такие серьезные ошибки выявляются в уже зарелизенной версии софта. В таких случаях, если не ошибаюсь, разработчик софта старается устранить сию ошибку максимально быстро и (внимание!!!) старается предупредить пользователей софта об таком своем конфузе, дабы по возможности предотвратить потенциальный урон.
Ну например, ошибка в софте бортового компьютера автомобиля, приводящая к проблемам с кондиционером - несерьезна, а вот если проблемы возможны в тормозной системе или, допустим, в работе подушек безопасности...А теперь представьте, что производители авто с такой ошибкой в программе бортового компьютера, доносят до вас "что ошибки есть в любом софте, но их проявление зависит от эксплуатации". Сомневаюсь, что вы будете достаточно к ним лояльны, особенно если сия ошибка проявится именно в вашем авто. Не дай Бог, конечно.

Только Вы забываете, что автомобиль на все 100% состоит их элементов, которые спроектировал сам производитель, возможно даже все 100% сам произвел и точно сам собрал и протестировал.
Будет ли все так же хорошо работать в автомобиле, если Вы соберёте его самостоятельно из ЗЧ разных производителей?

Серьезность ошибки в вашем софте вами осознается, очевидно. С момента её обнаружения прошло два месяца. Кроме высылки файлов УЖЕ пострадавшим от вашего кривокодия пользователям и попыток донести до меня, что-то ещё сделано, стесняюсь спросить?

Исправление - серьезное, сомнений нет. Что еще сделано - не могу сказать, у меня нет сведений.

Структура видеоархива, которая опирается на дату и время создания файла, не подходит для системы безопасности. Простота изменения пользователем даты и времени у видеофрагмента - удобный инструмент для подлога, фальсификации и т.д.

Есть такая штука - разграничение прав пользователя, большинство файловых систем включая NTFS такую штуку поддерживают. Странно, что мне приходится об этом говорить ведущему инженеру отдела проектных решений.

Перестаньте, разграничение прав в ОС обойдет любой "опытный пользователь" за 5 минут.

А при наличии неограниченных прав в системе (читай прав администратора) и ваш сложноструктурированный архив порушить - не проблема. А в последних версиях вашего софта для этого и прав особых не надо, достаточно использовать необходимые для работы VN права на изменение системного времени. Уже обсуждалось.

Порушить можно что угодно, и Windows и NTFS. Дело в простоте подлога и фальсификации. Предположим, что Вы охранник. Берем файл записи за день, когда Вы не заходили в кабинет директора, копируем его. Далее идем в кабинет директора и берем из бара бутылку алкоголя. Далее возвращаемся на место, дожидается когда файл с Вашими противоправными действиями будет сформирован системой, копируем его имя, удаляем файл, присваиваем это имя фалу скопированному нами до этого и кладем этот файл в папку с видеоархивом. На видео будет все в порядке.
Систем с подобным методом хранения архива - полно, просто никто не задумывается от этом, пока не случится беда...

Кроме того, такая структура архива не позволяет обеспечить необходимое быстродействие. Мы это проходили на VideoNet 7.
Пользователь хочет одновременно с записью воспроизводить синхронно и асинхронно несколько источников, архивировать видеозаписи, просматривать видео по сети, делать экспорт клипов и все одновременно. Уверен, что если Вы попробуете выполнить все те действия с видеоархивом которые Вы делаете на VN, на системах использующих описанную Вами структуру - Вы будете неприятно удивлены - они этого просто не смогут выполнить большую их часть.

И снова вы забываете, что ваши архивы пропадают. И мне, как пользователю, глубоко плевать, насколько быстродействующим был мой ПРОПАВШИЙ архив.
Что же касается низкого быстродействия файловых систем (а хоть и NTFS), которые сами по себе представляют своего рода БД, в сравнении с вашей сложноструктурированной БД - не уверен. Тестировали, говорите? Так выложите методику и результаты тестирования, а потом и поговорим. Особенно интересны таковые тесты на слабых машинах.

Подумайте над такой "простой" задачкой: в системе есть 32 камеры, запись ведется по детекции движения, срок хранения видео 30 суток. (самая стандартная ситуация).
1) Какого размера файлы с видео Вы планируете создавать? Размер файла будет ограничен именно размером или интервалом времени? При каком количестве файлов в папке ОС/файловая система начнет тормозить?
2) При окончании детекции, запись останавливается, файл закрывать, а при следующем старте записи открывать новый? От этого будет зависеть количество файлов, интервал времени который будет стираться при циклической очистке. Особенно это актуально если запись идет не 25 к/с, а 6 или 3 (не говоря уже про 0.1 к/с), так как файл в несколько мегабайт может содержать в себе десятки минут записи.
3) При циклической очистке как искать файл который надо удалить? Диск будет успевать?
4) Как обеспечить защиту важных фрагментов от циклического стирания?
5) Структура архива будет выглядеть как простой набор файлов от всех камер в одной папке или файлы от разных камер будет лежать в разных папках?
6) При записи всех 32 камер в режиме циклической очистки дисковый накопитель будет успевать? А если добавить воспроизведение?
7) Как обеспечить защиту от подлога,фальсификации....

Подобных вопросов - очень много, и всех их надо учесть.... ни одна из существующих файловых систем для этого не предназначена.

Я вообще-то упомянул такой способ хранения видеоархива в качестве не самого лучшего, но наиболее простейшего.
Однако этот способ обеспечит более высокую надежность архива, чем ваше решение. По той простой причине, что разработчики файловых систем просто не могут позволить себе релизить софт с такими серьезнейшими багами, как у вас.

Вы много знаете разработчиков файловых систем? Что это за компании? Ошибок там не возникает и файлы никогда не теряются (естественно надо проверять в аналогичных условиях - запись по циклу множества файлов, произвольный доступ на воспроизведение и т.д.)?

[Vibat]

Алгоритм простой: делаешь архивацию в том, всё. В проигрывателе это выглядит как отсутствие записей там, где они ранее существовали.На всех моих серверах стоит Win 2003 Server 32x.Основной том на оперативных серверах - софтовое зеркало размером ~500Гб, дополнительный том - пустое место на системном диске, размер варьируется. Архивация в дополнительный том с основного приводит к пропаданию архивов в доп.томе.Tом на сервере архивации - аппаратный райд размером ~7Tб. Архивация в него приводит к пропаданию архивов.Пропадают архивы только с dll-ками из версии, выложенной на сайте.Хотя вру, и на 88sp3 такая фигня случалась изредка. На 84 версии такого не было вроде бы.Не тыкайте с разбегу, не люблю панибратства.

Проблема наблюдается только на WS2003 ? А если Windows 7 ?

[Vibat]

Порушить можно что угодно, и Windows и NTFS. Дело в простоте подлога и фальсификации. Предположим, что Вы охранник. Берем файл записи за день, когда Вы не заходили в кабинет директора, копируем его. Далее идем в кабинет директора и берем из бара бутылку алкоголя. Далее возвращаемся на место, дожидается когда файл с Вашими противоправными действиями будет сформирован системой, копируем его имя, удаляем файл, присваиваем это имя фалу скопированному нами до этого и кладем этот файл в папку с видеоархивом. На видео будет все в порядке.Систем с подобным методом хранения архива - полно, просто никто не задумывается от этом, пока не случится беда...

Да уж давно на всех хоть немного уважающих себя предприятиях сервера установлены в серверных, а у охраны клиентские места, отдельные компьютеры.
Кроме того за охранниками, сидящими за компьютерами, следят специально установленные камеры.
Речь о том , что в результате простоты штатных действий , даже с клиента , запись сервера можно повредить, например на некоторое время остановить при синхронизации VN 8, или вообще уничтожить ( как у Duser-a )

[Duser]

Это не БД, а железо, более-менее успевало справляться с возложенными задачами.

Пусть так, Вам виднее, Вы - ведущий инженер в конце концов.
Я вычитал в "инструкции по инсталляции системы VideoNet" на 4 стр. следующее:
"1. Технические требования к системе
Требования к аппаратуре и программному обеспечению, установленному на компьютере, предназначенном для инсталляции системы VideoNet:
Процессор
Минимум: Pentium 4 2.4 ГГц Рекомендуется: Intel Core 2-го поколения с тактовой частотой от 2 ГГц
Оперативная память
Минимум: 512 Мб Рекомедуется: 2 Гб для систем до 32 камер, 4 Гб - для систем более 32 камер
...
Операционная система (32 bit)
Microsoft Windows XP SP3, Microsoft Windows Server 2003, 2008, 2012, Microsoft Windows Vista Business/Ultimate/Enterprise SP1 и т.д."

Мой сервер архивации и до апгрейда перекрывал не минимальные, но рекомендуемые параметры. А ныне он существенно мощнее (Xeon на серверной матери и 8 ГГб ОЗУ, ОС - Win 2003 х32).
Я наивно полагал, что выполнение этих требований обеспечит работоспособность системы. Особенно учитывая тот факт, что на моем сервере архивации ни сжатия видеоданных, ни детекции движения не производится, по сути на нем производится самое обыкновенное копирование файлов по сети. Я ошибался? Для чего тогда приведены тех.требования?
Хотя..."Этот документ предназначен только для информационных целей. Корпорация СКАЙРОС не дает никаких дополнительных гарантий относительно представленной здесь информации." - на 1 стр. того же документа. И Ваша позиция в этой дискуссии абсолютно в русле сей фразы.

Все понятно, Вам важно что бы работала Ваша система, Вы обратились в службу техподдержки и она Вам помогла.

Ну, "помогла" - это некоторое преувеличение. Спец саппорта дал некоторые рекомендации. Часть из них я выполнил (кое-какие настройки ОСи и рейд-массива, и даже замена железа), часть из них выполнить было невозможно (загрубление/изменение настроек детектора, установка другой ОСи), тем не менее в случае с программным рейдом проблема была решена разбивкой тома на более мелкие тома, что не совсем устраивало пользователей системы, а после апгрейда сервера и установки аппаратного рейда добиться нормальной надежной архивации не удалось до сих пор. Суть последней рекомендации саппорта сводится к тому, что программе не хватает ресурсов 32х битной ОСи.
Это тем более странно, что сервер архивации у меня занимается исключительно архивацией. А рядом пашут три оперативных сервера с куда менее мощным железом (Xeon и 8ГГб ОЗУ против Core 2 Duo и 2ГГб ОЗУ), и под той же ОСью W2003 x32 обрабатывают и сжатие и детекцию по 16 камерам каждый + оперативный архив на 500ГГб в программном зеркале, к которым пока нет претензий (тьфу-тьфу-тьфу!).

Только Вы забываете, что автомобиль на все 100% состоит их элементов, которые спроектировал сам производитель, возможно даже все 100% сам произвел и точно сам собрал и протестировал.
Будет ли все так же хорошо работать в автомобиле, если Вы соберёте его самостоятельно из ЗЧ разных производителей?

Уж не хотите ли Вы сказать, что написать сколько нибудь надежное ПО под машину, собранную из НЕсамоспроектированных запчастей и с установленной НЕсамописной ОСью невозможно?
Понимаете, есть такая штука "стандартизация", предназначена как раз для того, чтобы не было необходимости создавать с нуля весь автомобиль, или там самолет, или допустим PC-based видеосервер, без ущерба надежности безопасности и прочим качествам продукта. И, знаете ли, давно уже не состоит автомобиль или там самолет на 100% из самоспроектированного. Не знали? Про очень неплохой Суперджет почитайте, в нем процентов 80 комплектующих - не КБ Сухого. А надежность аппарата высокая. В отличие от...
Загляните на досуге хотя бы в Википедию, почитайте о стандартизации, ведущий инженер обязан такие вещи знать.
Что же касается "протестированности" - так я собираю сервера из протестированного вами оборудования, хотя это порой и не просто.

Исправление - серьезное, сомнений нет. Что еще сделано - не могу сказать, у меня нет сведений.

А в чьи обязанности входит предупреждать пользователей о критичных багах в ПО? Есть в вашей конторе такой человек? Просим на ковер.

Перестаньте, разграничение прав в ОС обойдет любой "опытный пользователь" за 5 минут.

Вы знаете, я считаю себя вполне опытным пользователем, однако способ обхода разграничения прав в ОС за 5 минут мне неизвестен.
Может расскажете КАК?
Конечно, не рассматривается вариант, когда у пользователя есть физический доступ к серверу и возможность загрузиться с liveCD/USB.

Порушить можно что угодно, и Windows и NTFS. Дело в простоте подлога и фальсификации. Предположим, что Вы охранник. Берем файл записи за день, когда Вы не заходили в кабинет директора, копируем его.
Далее идем в кабинет директора и берем из бара бутылку алкоголя. Далее возвращаемся на место, дожидается когда файл с Вашими противоправными действиями будет сформирован системой, копируем его имя, удаляем файл, присваиваем это имя фалу скопированному нами до этого и кладем этот файл в папку с видеоархивом. На видео будет все в порядке.
Систем с подобным методом хранения архива - полно, просто никто не задумывается от этом, пока не случится беда...

КАК мы его копируем/удаляем/переименовываем? У нас права есть? А если прав нету? К предыдущему вопросу возвращаемся, вобщем-то.

Подумайте над такой "простой" задачкой: в системе есть 32 камеры, запись ведется по детекции движения, срок хранения видео 30 суток. (самая стандартная ситуация).
...
Подобных вопросов - очень много, и всех их надо учесть.... ни одна из существующих файловых систем для этого не предназначена.

Да не мое это дело - думать над Вашей задачкой. Это ваше дело, коль скоро за якобы грамотное её решение вы берете с пользователей деньги.
И первым пунктом в Вашем тех.задании надо поставить обеспечение сохранности данных, поскольку при вероятности пропажи данных все прочие вкусности Вашего высокотехнологичного решения малоинтересны, а само решение следует признать ненадежной сырой бетой и срочно отправить на доработку, не забыв принести извинения и уплаченные деньги купившим сие поделие бедолагам.

А файловые системы я вам привел, как пример проверенного и надежного ПО для структурированного хранения данных (в том числе и видеоданных), в котором пропажа данных - очень серьезный баг. ФС с таким багом разработчики пользователям не предлагают, а тестируется такое ПО очень серьезно и очередной релиз в статусе беты висит до полного вылизывания.

Вы со своей "сложноструктурированной БД" попытались изобрести велосипед по сути, и сели в лужу. С момента перехода на новую структуру архива (с версии 8.0 кажется?) слёт всего архива в вашей "системе видеонаблюдения №1" - уже не баг, а фича. Одно время архив полностью слетал при некорректной перезагрузке системы, помнится, а в другой версии - при операции коррекции времени. Рекомендация опытных форумчан (а бывало и саппорта!) снести весь архив, чтобы система перестала глючить - этакое всесильное средство на все случаи, сродни совету переустановить винду, поскольку проще убить, как говорится. И это в системе безопасности!. Да чего говорить, форум профильный - все прекрасно понимаем, что такое есть видеоархив и какова цена его потери.

А вы слышали чтобы файловая система становилась нечитаема после подводки времени? Некорректная перезагрузка - бывшая во времена FAT тяжелым испытанием для файловой системы, давно уже таковым не является - ФС журналируемы (и NTFS тоже!). А Ваша БД слетала и слетает. Ныне, похоже, у нее исчерпывается лимит на количество файлов/видеоотрезков (что в мире ФС тоже давно решено) с ростом емкости накопителей. Потому и наблюдаются глюки на больших томах.
Так я и говорю: не можешь написать надежную "сложноструктурированную БД" - не мучай пользователя и инсталлятора, используй написанное профессионалами. Та же XFS имеет открытый код и создана для больших дисков, RaiserFS - свободна и заточена на быструю работу с мелкими файликами (4Кб). Да сотни их. NTFS, в конце концов, не так уж плоха.

Вы много знаете разработчиков файловых систем? Что это за компании? Ошибок там не возникает и файлы никогда не теряются (естественно надо проверять в аналогичных условиях - запись по циклу множества файлов, произвольный доступ на воспроизведение и т.д.)?

Microsoft, IBM, Apple, Sun, Oracle - это навскидку. А Вы зачем спросили? Информация вроде не секретная.
Запись по циклу множества файлов, произвольный доступ и т.д. - вполне стандартные функции любой ФС.
Доказать что явления никогда не было невозможно, а вот опровергнуть таковое утверждение легко одним контрпримером. Приведите пример бага с пропажей данных в стабильном релизе какой-нибудь ФС. Это будет интересно ещё и с точки зрения анализа реакции разработчиков на найденный баг в сравнении с Вашими неспешными действиями в аналогичной ситуации.

[Duser]

Проблема наблюдается только на WS2003 ? А если Windows 7 ?

На других ОСях не тестировал.

[Duser]

Единый том архивации 7,5Тб на аппаратном райде разбил на 6 томов по 1,2Тб. Система не вывозила -регулярно сбоила архивация. Попробовал отключать тома сначала по одному, а потом и по два.
Выяснилось следующее: только четыре тома по 1,2Тб достаточно сносно отрабатывает последняя версия VN с несколькими измененнными dll`ками от саппорта; архивация проходит в большинстве случаев успешно. Это на машине с Xeon`ом, брендовым аппаратным райдом и 8Ггб ОЗУ.
Ныне с помощью планировщика по вторникам и пятницам отключаем попеременно по два тома из шести. С таким костылем "система номер один" хоть как-то работает.
Вести с полей, как говорится.

А на сайте так и висит версия, в которой архивы пропадают при архивации. Когда можно будет забыть о пропадании архивов?

[Stranger]

To Duser: Константин, 27.02.2015 по Вашей ситуации Вам был предоставлен ответ следующего содержания:
---
Судя по присланным Вами данным, текущая конфигурация VideoNet на данном компьютере (7 томов суммарным объемом ~9TB, 3 сервера и клиент) без ведения архивации использует около 2.9GB виртуального адресного пространства. Соответственно, при ведении архивации VideoNet требуется более 3GB адресного пространства. В x86 операционной системе VideoNet не может использовать более 3GB виртуального адресного пространства.

Рекомендую заменить используемую x86 операционную систему на x64 ОС - это позволит VideoNet использовать 4GB виртуального адресного пространства. Возможно, этого будет достаточно для ведения архивации в данной конфигурации.

Прошу Вас сообщить о результатах.
---

Таким образом, в феврале ситуация была ясна и тогда же Вам был предложен вариант решения.
Возможно, замену ОС с x86 на x64 Вы так и не произвели (судя по тому, что Вам сейчас помогает отключение части томов, т.е., уменьшение использования VideoNet'ом виртуального адресного пространства).
Если же ОС была заменена на x64, но ситуацию это не исправило, прошу Вас вновь обратиться в службу поддержки по e-mail support@videonet.ru

По версии VN - сейчас на сайте по ссылке http://www.videonet.ru/index.php?id=293 доступна версия VideoNet 8.9 SP2

[Vibat]

Проблема наблюдается только на WS2003 ? А если Windows 7 ?

На других ОСях не тестировал.

В своё время я отказался от WS 2003 в пользу Windows 7 , визуально на том же железе (том в 3,5 ТБ ) , заработало ( в плане просмотра архивов ) гораздо быстрее.