Можно несколько вопросов задать: 1. Я правильно понял, что единица аллокации у вас 16МБ? Т.е. если записали 4КБ в том, то по факту заняли 16МБ физически? 2. Не очень понял почему CRC сохраняете на парные блоки? Почему просто отдельно на блок не храните? 3. В DIF отводится 16бит под CRC. Вам хватает CRC16 на практике или вы что-то другое используете? Слишком высокая вероятность коллизии у нее. 4. Как я понял страйп вы пишете inplace, т.к. не используете RedirectOnWrite, CopyOnWrite. Как вы гарантируете атомарность записи страйпа(проблема Raid Write Hole)? 4. TRAID у вас реализован в linux kernel?
Избыточно. Мы осознанно пошли на это, чтобы избежать порчи данных из-за ошибки в софте. При восстановлении данных с помощью EC версии проверяются и мы точно не получим мусор.
В целом версии несут в себе мало оверхеда по вычислению и хранению. Самый большой оверхед у версионирования - это "лишний и мутный" код, в котором тяжеловато разбираться =).
Я правильно понял что например в 4+2, у вас участвует 6 cs? Получается в отличие от схемы с репликами, если хотя бы 1 cs недоступен, оно становится read-only? Ну мб это ок так как только на холодный сторадж.
Да участвует 6 CS. С недоступностью не совсем так. В схеме 4+2 можно потерять и 2 CS и продолжить писать, но без отказоустойчивости. Сколько можно потерять CS и продолжить писать регулируется отдельным параметром и настраивается гибко. Для 4+2 мы выставляем этот параметр в 1, т.е. потеря одного CS не приводит к приостановке записи, а потеря 2-х CS переведет чанк в read-only.
А есть бенчмарки с какими-то из конкурентов?
Есть, но лично я считаю некорректным их выкладывать. В целом некоторые бенчмарки вендорских СХД или CEPH можно найти в открытом доступе.
encryption остается на пользователе виртуалки?
В моменте да. На самом деле наш SDS умеет в encryption и шифрованием занимается libclient. Но нам надо доделать хранение ключей шифрования во внешнем KMS, чтобы шифрование было доступно в публичном облаке. Скоро это будет.
Это неверно. Как я и писал в статье, что чем выше центр тяжести у обратного маятника, тем легче его стабилизировать. А как ваше кольцо снаружи не располагай, все равно получается трехмерный обратный маятник.
Для примера возьмите карандаш и попробуйте стабилизировать его на ладони в вертикальном положении. Затем возьмите стержень длиннее. Разницу сразу почувствуете.
Голова у BB-8 не имеет никакого функционального назначения. Это обычный sphero, просто сверху на магните или еще на чем-то держится голова. И как-то странно говорить, что под чего подстраивается.
С BB-8 данный шаробот не имеет почти ничего общего. У BB-8 центр тяжести находится ниже геометрического центра, поэтому ему не надо стабилизировать себя, он как неваляшка.
В итоге, такая идея конструкции сложна технически (чего стоят хитрые омни-колёса со скольжением в поперечной плоскости), но проста математически — двигаться можно тремя колёсами в любом направлении с помощью подбора тяги двух колёс из 3. (Похоже, именно поэтому и понадобились двигатели с управлением по току, что тоже удорожило.) Правда, есть и плюсы — беспроблемная ориентация столика, на котором можно расположить видеокамеру.
На самом деле такая конструкция самая простая в исполнении, именно поэтому я и выбрал её. Без омниколес не обойтись в любом случае. В каком положении не ставь обычные колеса, будет возникать большое трение и проскальзывание, что практически невозможно учесть в мат. модели и, следовательно, в управлении.
Управление по току понадобилось не по этой причине. Когда речь идет о стабилизации таких систем, управление может быть только по моменту(по току). Можно пробовать управлять по скорости и подбирать коэффициенты эмпирически, но не думаю что из этого выйдет что-то.
Наверняка, в обеих проектах такая идея прорабатывалась и даже уравнения движений, наверное, написаны (и модель в матлабе есть?)
Не очень понял про какие два проекта вы говорите. CMU и Rezero? Уравнения движения для них есть, но, как я писал выше, они составлены с учетом некоторых упрощений. Моделей в матлабе в открытом доступе у них нет.
Чтобы шар катился, как вы говорите, поперек колеса, существуют омниколеса. В нем нет никакого проскальзывания поперек колеса, только трение качения.
Стоять полностью неподвижно такое «устройство» никогда не сможет, т.к. мы находимся не в сферическом вакууме. Данный шаробот сохраняет равновесие в окружности примерно 5 см при отсутствии внешних воздействующих факторов. Стоять рядом с ним точно не опасно. Если его толкнуть, то, конечно, он поедет.
Спасибо за статью, очень интересно!
Можно несколько вопросов задать:
1. Я правильно понял, что единица аллокации у вас 16МБ? Т.е. если записали 4КБ в том, то по факту заняли 16МБ физически?
2. Не очень понял почему CRC сохраняете на парные блоки? Почему просто отдельно на блок не храните?
3. В DIF отводится 16бит под CRC. Вам хватает CRC16 на практике или вы что-то другое используете? Слишком высокая вероятность коллизии у нее.
4. Как я понял страйп вы пишете inplace, т.к. не используете RedirectOnWrite, CopyOnWrite. Как вы гарантируете атомарность записи страйпа(проблема Raid Write Hole)?
4. TRAID у вас реализован в linux kernel?
Избыточно. Мы осознанно пошли на это, чтобы избежать порчи данных из-за ошибки в софте. При восстановлении данных с помощью EC версии проверяются и мы точно не получим мусор.
В целом версии несут в себе мало оверхеда по вычислению и хранению. Самый большой оверхед у версионирования - это "лишний и мутный" код, в котором тяжеловато разбираться =).
Да участвует 6 CS. С недоступностью не совсем так. В схеме 4+2 можно потерять и 2 CS и продолжить писать, но без отказоустойчивости. Сколько можно потерять CS и продолжить писать регулируется отдельным параметром и настраивается гибко. Для 4+2 мы выставляем этот параметр в 1, т.е. потеря одного CS не приводит к приостановке записи, а потеря 2-х CS переведет чанк в read-only.
Есть, но лично я считаю некорректным их выкладывать. В целом некоторые бенчмарки вендорских СХД или CEPH можно найти в открытом доступе.
В моменте да. На самом деле наш SDS умеет в encryption и шифрованием занимается libclient. Но нам надо доделать хранение ключей шифрования во внешнем KMS, чтобы шифрование было доступно в публичном облаке. Скоро это будет.
Часть которая отвечает за метаданные(MDS) на Golang. Часть которая отвечает за данные(CS) на C++.
Для примера возьмите карандаш и попробуйте стабилизировать его на ладони в вертикальном положении. Затем возьмите стержень длиннее. Разницу сразу почувствуете.
https://www.youtube.com/watch?v=A_K10fX9DSY
Управление по току понадобилось не по этой причине. Когда речь идет о стабилизации таких систем, управление может быть только по моменту(по току). Можно пробовать управлять по скорости и подбирать коэффициенты эмпирически, но не думаю что из этого выйдет что-то.
Не очень понял про какие два проекта вы говорите. CMU и Rezero? Уравнения движения для них есть, но, как я писал выше, они составлены с учетом некоторых упрощений. Моделей в матлабе в открытом доступе у них нет.
Я ответил на ваши вопросы?
Стоять полностью неподвижно такое «устройство» никогда не сможет, т.к. мы находимся не в сферическом вакууме. Данный шаробот сохраняет равновесие в окружности примерно 5 см при отсутствии внешних воздействующих факторов. Стоять рядом с ним точно не опасно. Если его толкнуть, то, конечно, он поедет.