Как стать автором
Обновить

Комментарии 22

Как восстанавливать данные, если все диски целы, а, например, в контроллер попал метеорит?
Где хранятся данные о расположении блоков?
На дисках конечно. В случае замены контроллера данные будут полностью доступны.
Не окажется область хранения данных о блоках точкой ненадежности? Или она тоже перемещается для равномерного износа?
Не так уж и страшно, что данные на SSD пишутся в одно и то же место, т.к. в случае износа этого пространства блоки ремапятся из резервного объема накопителя.
А всего-то надо забросить raid5 на свалку истории и забыть как страшный сон.
У RAID1 хоть и ниже penalty тоже хватает недостатков в плане разброса блоков с данными по накопителю.
не получится. У каждого SSD свои мозги и сквозной оптимизации все равно не выйдет. Производители просто не покажут что там под капотом.
Ну так и у предложенного решения ее не будет.
Разумеется, внутрь SSD не удастся «влезть». Но перегруппировать входящие данные так, чтобы накопитель думал, будто бы на него в последовательном режиме пишут, возможно. Что, собственно, и реализовано.
ИМХО это еще хуже. Пытаться перемудрить контроллер накопителя учитывая, что у него внутри совершенно не тривиальные алгоритмы, да и организация памяти может иметь множество вариантов.
Плюс на все это наложить ограничения рэйдов высокого уровня которые очень критичны к отказам при ребилде. Идя прямо скажем не очень.
Хочется управлять накопителями, нужно с производителем работать над прошивкой, другие варианты чреваты.
Основная идея — не перехитрить контроллер накопителя, а подстроиться под его режим работы, ведя учет за расположением данных на нем.
Для этого вы должны уметь предсказывать его поведение. А для этого вы должны иметь доступ к алгоритмам которые в него заложены.
Так доступ к глубинным алгоритмам и не требуется. При последовательной работе записи/перезаписи поведение одинаково для всех современных накопителей. Если есть разница, например, в триггерах, по которым работает «сборщик мусора», то в глобальном смысле это не так уж и важно, т.к. на общую производительность данное обстоятельство слабо влияет.
При последовательной работе записи/перезаписи поведение одинаково для всех современных накопителей.

Не верю. nApoBo3 прав. Сюда по описаниям своих дисков производителями, они закладывают самые различные алгоритмы для уменьшения износа, увеличения скорости и т.п. в свои контроллеры. Поэтому как можно такое утверждать? Почему на абсолютно одинаковой памяти разные контроллеры показывают сильно разные результаты даже «при последовательной работе»? Что отображается на их ценах, кстати.

Теперь субъективное. Язык ваших статей очень, очень ужасен. Срочно уходите от этой казённо-маркетинговой подачи. Вы не на помпезной презентации, а в Хабре. Куча воды, много красивых слов, а суть растянута и тонет в болоте. Как будто прилежному ученику дали задание на сочинение на заданную тему не менее 5-ти страниц (как вспомню подобный идиотизм в школе, так вздрогну).
Начал читать и с удивлением обнаружил, что ссылки уже хожены (подсвечены). Был бы нормальный материал — вспомнил бы с первых же предложений.
А что мешает просто собирать поступающие друг за другом на запись случайные запросы и записывать их только блоком по мере его наполнения, помечая неактивным только старый адрес перезаписанных данных (а сами данные пусть там пока остаются)? А по мере прохождения критической массы либо изменений в конкретном блоке, либо сокращения свободного места на накопителе/группе накопителей, либо снижении интенсивности запросов на запись ниже предельной (освобождение очереди и переход в idle) заняться чтением и перезаписью блоков с наибольшим числом устаревших адресов. При таком подходе явно же сократится общее число необходимых операций перезаписи, а высвобождающееся таким образом время доступности накопителя, как раз позволит спокойнее и чаще заниматься менеджментом «старых адресов». Цена вопроса — всего лишь некоторый (оперативный, но обязательный) запас свободного места на накопителе.
Не берусь в полной мере оценивать эффективность вашего метода. Вполне возможно, что это будет работать. Тем более, что в некотором приближении напоминает подход Nettap. Но в наших продуктах применен описанный в статье механизм.
А так ли важен сборщик «мусора» в Энтерпрайз сегменте?
Все проблемы SSD выходят из того, что есть новая технология, но в целях совместимости ее используют как HDD, а чтоб продлить срок службы и тому подобное, прозрачно для пользователя, в контролеры вшивают непонятный функционал, который потом вываливается в тормоза.
От сильно умных контроллеров в SSD надо избавляться и переносить логику на файловую систему, нужны новые ФС, вроде как NTFSfromSSD, ext3/4fromSDD или просто новая SSDFS, и контроллеры RAID должны научится вести себя по другому с SSD.
п.с. это моя точка зрения, может я и не прав.
Полностью поддерживаю, это решение просто напрашивается.
Справедливости ради, что вы хотите от этой конторы, если даже каждый гигант отрасли тоже лепит свои уникальные костыли в своих хранилках. Все боятся трогать проверенные технологии, проще сверху слепить.
Ребят, у вас там всё хорошо?

Как так получилось, что у компании, продвигающей передовую технологию, сайт работает по http, а https://accelstor.ru говорит «It works» и сертификат там некорректный?
Это ведь даже не nginx, это apache.
image
Ну зайдите на английскую версию, раз вам так хочется непременно https.
Чёрт, если бы увидел этот посыл автора раньше, не тратил бы время на свой верхний коммент.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.