Присоединяюсь к поздравлениям. Хотя гораздо приятнее было бы почитать как молодое поколение вливается в разработку СПО вне рамок подобного рода соревнований.
Кстати, замечательная постановка вопроса. Цимес в том что как раз большая часть свободного софта не имеет GUI, и это замечательно, потому что в то время как в коммерческом ПО GUI очень часто притягивается за уши (кто же купит программу без скриншота?) и получается либо окно с кнопкой (которое приходится обвешивать всякой ерундой иначе скучно), либо пульт управления боингом с десятком вкладок, с CLI работается на порядок эффективнее — нужные опции мгновенно ищутся в man или --help, а то что сложно запомнить скриптуется один раз на всю жизнь. Да и в любом случае скриптуется, собирается в конвееры, работает из cron, по ssh и т.д.
> вы знаете, которые могут похвастаться качеством, юзабилити и стабильностью?
Ну про стабильность можно даже не заикаться, качество — интегральная характеристика под которой не совсем понятно что в данном случае понимается, а вот юзабилити про которую идёт речь выше — штука очень субъективная. Многим будут удобнее интерфейсы написанные разработчиками под себя, а не под широкую аудиторию. Поэтому лично для меня ответ на ваш вопрос — «все, что я знаю, могут похвастаться».
> без участия дизайнеров и архитекторов интерфейса
Не нужно забывать насколько сомнительные решения зачастую получаются с их учатием. HIG, ribbon, плитки win8, некоторые макосевские решения, продолжать можно долго.
А что это за яркий объект в середине нижнего края первых снимков (зелёный)?
Почему видно деревья и дома (а не просто они закрывают спутники)? По идее, они отражают излучение из-за «спины» антенны, а откуда оно там? Сигнал спутников уже отражённый от земли и других зданий?
> при наличии HDOP и количества спутников «кляксы» и откровенный мусор удаляются автоматически почти полностью
Накакой связи, абсолютно. Со стоянками вообще всё просто — они остаются стоянками независимо от точности и независимо же от точности могут вырезаться, как автоматически так и вручную. Касательно треков в целом, про количество спутников можно сразу забыть ибо оно ничего не значит без как минимум положения этих спутников, а HDOP (куда и то и другое неявно включено) ничего не значит как минимум без точной модели устройства потому что считается каждым по-своему и, опять таки, с реальной точностью мало связан. На деле откровенный мусор легко определяется только по координатным данным.
> «Крайне полезны» без очистки они будут только при условии, что кто-то почешется и разберет их абсолютно все
Почему обязательно «абсолютно все»? Любое количество треков будет полезно и сразу разбирать их все кому-то совершенно не обязательно.
Данные о спутниках совершенно не обязательны — в OpenStreetMap треки будут крайне полезны в любом случае. Хотя опять таки в любом случае понадобится ручная или полуручная их обработка с целью удаления «клякс» на стоянках и явно кривых участков.
Код написанный в notepad и под windows от оных никак не зависит. А вот ваш проект, увы, полностью зависим от проприетарного API и проприетарных карт. Открытый можно было бы сделать на osm/leaflet/osrm, например. И качество карт, к слову, было бы намного лучше: вот пример такого сервиса, но как я понял, фишка вашего — использование роутинга.
А они вообще были degraded? Журнал используется? До этого в каком они состоянии были?
Факт в том что чтобы знать что синхронизировать на диске как минимум должны храниться метаданные о поколении каждого блока, а их нет — метаданные gmirror занимают всего один сектор. Как я понял из беглого чтения исходников gmirror, всё что он умеет — запоминать сколько данных синхронизировано, поэтому если перезагрузиться в процессе ресинхронизации она продолжится с того же места на котором прервалась. Но если при перезагрузке у дисков не совпали syncid (число, увеличивающееся при каждой записи и хранящееся в том самом секторе с метаданными), что очень вероятно после «грязной» перезагрузки (один диск записал этот сектор, второй не успел), диск с меньшим syncid будет синхронизирован полностью.
Это всё понятно, но я всё же вижу противоречия и не вижу логики. RAID делается, значит наверное данные важные, бэкапы не делаются, значит наверное не важные. Затрагивается тема bit flip, значит наверное пипец какие важные, однако потом выясняется что периоды когда зеркало находится без избыточности и потеря одного зеркала из нескольких некритична. Вполне возможно что raid тут и не нужен совсем, а диски можно было пустить под бэкапы.
А касательно потери информации, речь как-бы идёт не об одном файле из полумиллиона, а о значительной части — половине или трети. Толку будет от того что потеряно не всё, если именно то что нужно в данный конкретный момент потеряно?
Процитированная фраза некорректна. Во-первых, jail это не виртуальная машина (песочница — да, аналог chroot). Во-вторых, «всё что успел родить Open Source» можно нативно запустить на FreeBSD.
А касательно вопроса — достаточно сделать chroot/jail в директорию куда распакован/смонтирован Linux дистрибутив — благодаря бинарной совместимости внутри этого chroot будут работать исполняемые файлы Linux в родном для них окружении. Подробнее: www.freebsd.org/doc/en/books/handbook/linuxemu.html
У этой совместимости есть свои ограничения — в частности, она довольно сильно отстала от оригинала, поэтому заработают только бинарники под достаточно старые версии ядра. В дереве портов есть рабочие «linux base» окружения от Fedora 10 и CentOS 6 — можно играться с ними.
> вижу, что на пост пришел таки специалист по хранению данных:) Давайте подумаем вместе.
Я далеко не специалист по хранению данных, но 2 и 2 сложить могу.
> Вероятность второго механического отказа при реконструкции RAID5 сопоставима с моим разборным массивом из N томов-зеркал
Пусть вероятность выхода из строя диска при штатном использовании — p, вероятность выхода из строя при нагрузке возникающей при ребилде — P. Тогда с RAID5 вероятность потерять данные составит ~ p * (Nдисков-1) * P (навернулся один диск + навернулся второй при ребилде). С зеркалами это будет P * Nзеркал * Nребутов (считаем worst-case, т.е. все зеркала перестраиваются при ребуте) — напомню что когда gmirror перестраивается это по сути один диск без какой-либо избыточности, зато под нагрузкой. Не берусь считать какая вероятность больше и насколько, но игнорировать вторую никак нельзя. Потерю лишь части данных я за плюс не считаю — это всё равно потеря данных.
> В моем случае есть теоретически обоснованная устойчивость к URE
Обоснованная чем? Устойчивости к URE быть не может — если есть вероятность не прочитать блок то рано или поздно он не будет прочитан, если в этот момент не будет избыточности то ой.
> Наконец, скорость
> Не забываем про разборность и оффлайн хранение
Я замечу что агитирую не за «RAID5 вместо зеркала» а всего лишь за «RAID который не пересобирается целиком при ребуте». ZFS умеет и зеркало и несколько независимых массивов — соответственно ни со скоростью ни с отключением отдельных зеркал проблем не имеет, даже наоборот — можно воткнуть новый диск, переехать половину зеркала на него без уменьшения избыточности, а старую половинку убрать в архив, с возможностью восстановить зеркало из неё. Да и на raidz (RAID5) проблем со скоростью я лично не ощущаю — у меня 16T raidz2 (с двойной чётностью) на ST3000VX000-1CU166 даёт 300MB/s линейного чтения в обычном состоянии и почему-то 350MB/s в degraded без одного диска — в любом случае этого хватит чтобы записать новый диск на полной скорости.
> В целом ремонтопригодность у UFS / GEOM RAID1 считаю ощутимо выше, чем у RAID5 и у ZFS
Тут я соглашусь, учитывая простоту UFS, количество и обкатанность утилит. Однако целесообразней мне всё равно видится выбор ФС которая с большей вероятностью не потребует «ремонта» + бэкапы важных данных. А так у zfs есть утлита zdb — если совсем припечёт всегда можно расковырять том ей.
Мне казалось что наличие ERC в современных дисках — уже правило. Хотя это мнение основано на нерепрезентативной выборке, но в обычных десктопных сигейтах ~пятилетней давности ERC уже был. Кроме того, основной смысл — в его правильной настройке, критерием для которой является только факт использования диска в массиве с избыточностью.
> Про UFS / GEOM такого же красного флага не увидел, если не лень, дайте, пожалуйста, ссылку
Это должно быть очевидно и без флагов — повреждение памяти всегда приводит к непредсказуемым последствиям, независимо от ФС они могут стать фатальными. А вообще в том же исследовании есть глава 7 Beyond ZFS где в двух словах описывется такой же эксперимент с ext2 которую можно считать относительно близкой к UFS по структуре.
> Отказы geom mirror на сбросе питания — согласен, фигово и медленно, но шпалу переложить проще, чем заново натянуть вантовый мост:)
С одной стороны, вы пишете про «миф о RAID5» и связанную с ним опасность, с другой полная пересборка зеркала вас устраивает. Как-то это нелогично.
И думаю не лишним будет в очередной раз привести ссылку на пост про SCT Error Recovery Control (http://habrahabr.ru/post/92701/) который стоит иметь в виду при настройке RAID'ов дабы обеспечить адекватное поведение массива при появлении битых секторов на одном из дисков.
Добавлю что в портах FreeBSD есть скрипт (http://www.freshports.org/sysutils/scterc) который позволяет настроить ERC на дисках при загрузке системы (сами по себе диски не сохраняют настройки ERC между перезагрузками).
> Ого, как вам отказ всего массива на кучу ТБ из-за ошибки ОЗУ?
> Поэтому без лишних сожалений откладываем ZFS в сторону.
Только вот другие ФС и софтрейды ровно также «was not specifically designed to tolerate memory corruptions» и им снесёт крышу от флипа бита абсолютно также вплоть до полной невозможности восстановить данные, а в статье это почему-то представлено как ZFS-специфичная проблема.
Более того, именно ZFS благодаря чексуммам имеет все шансы обнаружить ошибку и не допустить битые данные до пользователя (а обнаружение ошибок скорее всего и является причиной «file system operations fail, and many times the whole system crashes», и именно это должно происходить при повреждении памяти вместо «тихого» чтения мусора вместо данных и повреждения ФС), а благодаря версионной архитектуре даже при повреждении данных на дисках в теории откатиться до рабочего состояния.
Мне посчастливилось словить не просто bit flip, а полноценно битую планку памяти сыпавшую мусором, и у меня есть основания полагать что только благодаря ZFS данные на дисках остались в сохранности — более того, после scrub я это знаю точно.
Касательно geom mirror — насколько я помню, оно очень любило разваливаться после перезагрузки по питанию, после чего восстанавливалось полным копированием одного диска на другой с очевидными последствиями для производительности и надёжности.
Принимай поздравления!
Есть основания полагать что именно с этого.
Кстати, замечательная постановка вопроса. Цимес в том что как раз большая часть свободного софта не имеет GUI, и это замечательно, потому что в то время как в коммерческом ПО GUI очень часто притягивается за уши (кто же купит программу без скриншота?) и получается либо окно с кнопкой (которое приходится обвешивать всякой ерундой иначе скучно), либо пульт управления боингом с десятком вкладок, с CLI работается на порядок эффективнее — нужные опции мгновенно ищутся в man или --help, а то что сложно запомнить скриптуется один раз на всю жизнь. Да и в любом случае скриптуется, собирается в конвееры, работает из cron, по ssh и т.д.
> вы знаете, которые могут похвастаться качеством, юзабилити и стабильностью?
Ну про стабильность можно даже не заикаться, качество — интегральная характеристика под которой не совсем понятно что в данном случае понимается, а вот юзабилити про которую идёт речь выше — штука очень субъективная. Многим будут удобнее интерфейсы написанные разработчиками под себя, а не под широкую аудиторию. Поэтому лично для меня ответ на ваш вопрос — «все, что я знаю, могут похвастаться».
> без участия дизайнеров и архитекторов интерфейса
Не нужно забывать насколько сомнительные решения зачастую получаются с их учатием. HIG, ribbon, плитки win8, некоторые макосевские решения, продолжать можно долго.
Почему видно деревья и дома (а не просто они закрывают спутники)? По идее, они отражают излучение из-за «спины» антенны, а откуда оно там? Сигнал спутников уже отражённый от земли и других зданий?
Если они действительно «научились учиться», вопроса «как быть» перед ними не стоит — они уже получают актуальные знания и необходимый опыт.
Накакой связи, абсолютно. Со стоянками вообще всё просто — они остаются стоянками независимо от точности и независимо же от точности могут вырезаться, как автоматически так и вручную. Касательно треков в целом, про количество спутников можно сразу забыть ибо оно ничего не значит без как минимум положения этих спутников, а HDOP (куда и то и другое неявно включено) ничего не значит как минимум без точной модели устройства потому что считается каждым по-своему и, опять таки, с реальной точностью мало связан. На деле откровенный мусор легко определяется только по координатным данным.
> «Крайне полезны» без очистки они будут только при условии, что кто-то почешется и разберет их абсолютно все
Почему обязательно «абсолютно все»? Любое количество треков будет полезно и сразу разбирать их все кому-то совершенно не обязательно.
Факт в том что чтобы знать что синхронизировать на диске как минимум должны храниться метаданные о поколении каждого блока, а их нет — метаданные gmirror занимают всего один сектор. Как я понял из беглого чтения исходников gmirror, всё что он умеет — запоминать сколько данных синхронизировано, поэтому если перезагрузиться в процессе ресинхронизации она продолжится с того же места на котором прервалась. Но если при перезагрузке у дисков не совпали syncid (число, увеличивающееся при каждой записи и хранящееся в том самом секторе с метаданными), что очень вероятно после «грязной» перезагрузки (один диск записал этот сектор, второй не успел), диск с меньшим syncid будет синхронизирован полностью.
А касательно потери информации, речь как-бы идёт не об одном файле из полумиллиона, а о значительной части — половине или трети. Толку будет от того что потеряно не всё, если именно то что нужно в данный конкретный момент потеряно?
А касательно вопроса — достаточно сделать chroot/jail в директорию куда распакован/смонтирован Linux дистрибутив — благодаря бинарной совместимости внутри этого chroot будут работать исполняемые файлы Linux в родном для них окружении. Подробнее: www.freebsd.org/doc/en/books/handbook/linuxemu.html
У этой совместимости есть свои ограничения — в частности, она довольно сильно отстала от оригинала, поэтому заработают только бинарники под достаточно старые версии ядра. В дереве портов есть рабочие «linux base» окружения от Fedora 10 и CentOS 6 — можно играться с ними.
Я далеко не специалист по хранению данных, но 2 и 2 сложить могу.
> Вероятность второго механического отказа при реконструкции RAID5 сопоставима с моим разборным массивом из N томов-зеркал
Пусть вероятность выхода из строя диска при штатном использовании — p, вероятность выхода из строя при нагрузке возникающей при ребилде — P. Тогда с RAID5 вероятность потерять данные составит ~ p * (Nдисков-1) * P (навернулся один диск + навернулся второй при ребилде). С зеркалами это будет P * Nзеркал * Nребутов (считаем worst-case, т.е. все зеркала перестраиваются при ребуте) — напомню что когда gmirror перестраивается это по сути один диск без какой-либо избыточности, зато под нагрузкой. Не берусь считать какая вероятность больше и насколько, но игнорировать вторую никак нельзя. Потерю лишь части данных я за плюс не считаю — это всё равно потеря данных.
> В моем случае есть теоретически обоснованная устойчивость к URE
Обоснованная чем? Устойчивости к URE быть не может — если есть вероятность не прочитать блок то рано или поздно он не будет прочитан, если в этот момент не будет избыточности то ой.
> Наконец, скорость
> Не забываем про разборность и оффлайн хранение
Я замечу что агитирую не за «RAID5 вместо зеркала» а всего лишь за «RAID который не пересобирается целиком при ребуте». ZFS умеет и зеркало и несколько независимых массивов — соответственно ни со скоростью ни с отключением отдельных зеркал проблем не имеет, даже наоборот — можно воткнуть новый диск, переехать половину зеркала на него без уменьшения избыточности, а старую половинку убрать в архив, с возможностью восстановить зеркало из неё. Да и на raidz (RAID5) проблем со скоростью я лично не ощущаю — у меня 16T raidz2 (с двойной чётностью) на ST3000VX000-1CU166 даёт 300MB/s линейного чтения в обычном состоянии и почему-то 350MB/s в degraded без одного диска — в любом случае этого хватит чтобы записать новый диск на полной скорости.
> В целом ремонтопригодность у UFS / GEOM RAID1 считаю ощутимо выше, чем у RAID5 и у ZFS
Тут я соглашусь, учитывая простоту UFS, количество и обкатанность утилит. Однако целесообразней мне всё равно видится выбор ФС которая с большей вероятностью не потребует «ремонта» + бэкапы важных данных. А так у zfs есть утлита zdb — если совсем припечёт всегда можно расковырять том ей.
Это должно быть очевидно и без флагов — повреждение памяти всегда приводит к непредсказуемым последствиям, независимо от ФС они могут стать фатальными. А вообще в том же исследовании есть глава 7 Beyond ZFS где в двух словах описывется такой же эксперимент с ext2 которую можно считать относительно близкой к UFS по структуре.
> Отказы geom mirror на сбросе питания — согласен, фигово и медленно, но шпалу переложить проще, чем заново натянуть вантовый мост:)
С одной стороны, вы пишете про «миф о RAID5» и связанную с ним опасность, с другой полная пересборка зеркала вас устраивает. Как-то это нелогично.
Добавлю что в портах FreeBSD есть скрипт (http://www.freshports.org/sysutils/scterc) который позволяет настроить ERC на дисках при загрузке системы (сами по себе диски не сохраняют настройки ERC между перезагрузками).
> Поэтому без лишних сожалений откладываем ZFS в сторону.
Только вот другие ФС и софтрейды ровно также «was not specifically designed to tolerate memory corruptions» и им снесёт крышу от флипа бита абсолютно также вплоть до полной невозможности восстановить данные, а в статье это почему-то представлено как ZFS-специфичная проблема.
Более того, именно ZFS благодаря чексуммам имеет все шансы обнаружить ошибку и не допустить битые данные до пользователя (а обнаружение ошибок скорее всего и является причиной «file system operations fail, and many times the whole system crashes», и именно это должно происходить при повреждении памяти вместо «тихого» чтения мусора вместо данных и повреждения ФС), а благодаря версионной архитектуре даже при повреждении данных на дисках в теории откатиться до рабочего состояния.
Мне посчастливилось словить не просто bit flip, а полноценно битую планку памяти сыпавшую мусором, и у меня есть основания полагать что только благодаря ZFS данные на дисках остались в сохранности — более того, после scrub я это знаю точно.
Касательно geom mirror — насколько я помню, оно очень любило разваливаться после перезагрузки по питанию, после чего восстанавливалось полным копированием одного диска на другой с очевидными последствиями для производительности и надёжности.