Может глюк с распознаванием ID партиций.
Тут пока руками не потрогаешь — понять не получится.
Если не затруднит, будьте так любезны создать запрос в техподдержку по этому поводу.
Случай интересный и жалко будет его не передать на рассмотрение инженерам.
Тут уже музыканту решать, насколько ему дороги его файлы.
Только это имеет значение.
Бэкап или реплика все равно требуется, абсолютно надежных вещей не бывает.
Ничего забавного и спекулятивного тут нет.
Достаточно вспомнить, как работает NAND на запись.
Напомню…
1. Ячейку NAND нельзя перезаписать, как это происходит с магнитным доменом, который просто перемагничивается.
2. Прежде чем ячейку перезаписать, её нужно стереть, а потом еще и записать.
3. Стирание и запись в NAND существенно медленнее, чем чтение.
4. Стирание, запись и чтение ячеек всегда идут блоками, по одиночке ячейки не стирают.
Далее идут еще более сложные вещи, как выравнивание износа, сборка мусора.
Действительно, если заставлять SSD все время сбрасывать свои буферы на медию, получим 300 — 700 IOPS на запись (полная корреляция с tProg для страницы), хотя есть производители, которые просто игнорируют такие команды, причем весьма именитые…
Когда SSD защищен по питанию смысла заставлять его сбрасывать буферы после каждой операции — нет.
Просто SSD вынужден ждать пока все страницы будут записаны и только потом приступать к обработке очередной команды.
Кроме потери скорости, начинает расти WAF (Write Amplification Factor), что приводит к увеличению износа NAND.
А в SSD мы платим только за запись, так зачем платить больше?
NL SATA и прочие HDD будут «сожраны», когда разница между $/GB станет менее 2х раз, а data retention приблизится к показателю магнитной медии.
У производителей HDD есть еще несколько козырей в рукаве, а NAND пока далеко не лучшая технология для длительного хранения данных.
SAS/FC останется пока из-за поддержания вложений в инфраструктуру.
SSD же требуют своих протоколов (им ATA и SCSI как собаке — пятая нога), и скорее всего на ближайшее будущее таковым станет NVMe.
Чисто технически — нет проблем выпустить и сейчас.
Вопрос только, сколько денег за ГБ готовы отдать?
Если прям так необходимо 2 ТБ, то можно взять и серверный, хуже не будет.
Весь вопрос, а зачем в коньсьюмерщине сейчас 2ТБ и выше?
Совсем просто станет делать 2ТБ и больше после выхода нового контроллера JetExpress.
А удешевление NAND произойдет с переходом на TLC, 4LC, 8LC и т.д.
Реалистично — начало следующего года, хотя не думаю, что SSD выше 2ТБ будут иметь большой успех в потребительском сегменте.
Для простого хранения данных есть внешние HDD или облачные сервисы. Скоростей современных сетей уже достаточно для доступа практически к любому контенту.
Есть хоть один пример выхода из строя Intrepid (именно этой серии) после внезапного отключения питания?
Серия Intrepid ничего общего с потребительскими SSD не имеет, да и глюков у чипа Marvel, что-то я не припоминаю.
А количество «оленей», как Вы выражаетесь, только в России в 2014 году составило процентов эдак 20-22 в канале, и растёт.
Не всегда он добрый получается…
Были случаи на SF контроллерах, правда. Что FW лочил сразу все SSD в RAID или сразу несколько SSD, а из этого состояния выход только один — secure erase. Причем взлом FW давал возможность запустить SSD без secure erase, но таблицы все равно были затерты :(
Вот такая печалька…
Новое поколение контроллеров в этом не замечено пока :)
А еще бывают пожары, потопы и человеческий фактор, т.е. когда все накопители рядом — риск потери всего и сразу все же выше, в сравнении с методом размещения данных во множестве мест.
Это я к тому, что RAID не всемогущий, бэкап или реплика все равно необходимы. Не стоит только на RAID полагаться.
Шифрование не является единственной помехой для восстановления данных.
Все реально восстановить, вопрос только денег и времени… Как в любом деле — проще предотвратить беду, чем потом героически, что-то там восстанавливать. Репликация критичных данных прекрасно решает проблему. (Не RAID — эта хрень только для механики годна...) SSD как правило «цепляют простуду» коллективно, т.к. воздействие — коллективное на них.
Данные на SSD всегда хранятся вперемешку, т.е. можно сказать скремблированы, это природа SSD, её не поменять.
Понять, где, что хранится, позволяют таблицы, вот их-то потеря и вызывает видимую «смерть» SSD. (на самом деле такой SSD можно восстановить заводским методом прошивки, хотя данные будут утеряны, либо secure erase, если служебные таблицы хотя бы остались.)
Контроллеры потребительских SSD и стоковые FW под них, в силу своей простоты и дешевизны, не могут заботиться о сохранности таблиц во время внезапного пропадания питания или сбоев по питанию, от того и мрут потребительские SSD — часто и с удовольствием, если не защищены бесперебойниками.
Но ситуация — меняется, проектируются новые контроллеры (хотя дело это дорогое и не быстрое), SSD уходят от ATA команд, которые им как собаке пятая нога, писатели FW все больше уделяют внимания сохранности таблиц их дублированию или хотя бы сохранности работоспособности SSD после сбоя.
Зоопарк всевозможных «производителей» SSD сужается, всего год назад их было более 135, сейчас уже меньше 130 ;) Прогресс! Проще стандартизировать процессы и технологии.
А шифрование, только слегка подливает масла в огонь, но не является первопричиной проблемы.
Например Vector 180 — будет иметь частичную защиту главных таблиц, что позволит им как минимум остаться работоспособными, хотя есть вероятность потери данных. (В лаборатории не получилось их потерять, но уверен, что россияне найдут способ!) Очереди за ними точно не будет.
Intrepid 3600 — полная защита по питанию и RAID на N+1 на NAND, нет очередей за ними, что-то. А ведь там не Sand Force полный сюрпризов, как его не программируй…
В следующее поколение контроллеров уже будет встроен еще более продвинутый механизм защиты таблиц размещения, и контроль питания.
FW будет более продвинутой. Не все сразу, забыли как первые HDD работали?
Я бы ставил вопрос иначе — не «как мне восстановить данные?», а «что делать, что бы не потерять их»!
Скоростью, значительно более низкими задержками, надежностью, наличием end to end data protection, отсутствием необходимости иметь свободные слоты и порты под SATA…
И как справедливо замечено ZD-XL — это решение, можно и TempDB туда положить и кэшировать, одновременно, причем кэшировать можем базы огромного размера, сотни ТБ!
Тесты CrystalMark и подобные пакеты, не способны показать всю печаль (да и делали их для маркетинга SSD), на которую обрекают себя люди, решившие использовать SSD потребительского класса в серверах или серверных нагрузках. Эти же тесты демонстрируют, что серверные SSD вообще не имеют смысла, т.к. они медленнее получаются своих потребительских собратьев по тестам CrystalMark и аналогам.
Люди не понимают, что размер тестового файла у «попсовых» пакетов — десяток, максимум сотня мегабайт. Их запускают на SSD обязательно после Secure Erase и без прекондиционирования, один раз, без достижения ssd steady state.
Их задача показать максимум, сферического коня в вакууме, а что там потом — это не важно… Как этот SSD будет работать после одной перезаписи?
Plextor M6e — это обычная попытка продать залежалые M2 хоть как-то… Результаты на запись и смешанными блоками — у него печальные… Ну не серверный это SSD…
Потестируйте настольные SSD с помощью HammerDB… hammerora.sourceforge.net/
Всё сами поймёте. Пока базу только создадите, большая часть потребительских SSD просто сдохнет либо физически, либо будет медленнее HDD…
Честно говоря, не ожидал такого вопроса, да же обидно, прям как будто не читали…
ZD-XL — это когда нет возможности или желания, что-то кардинально менять в железе. Это решение для существующих систем! Если есть возможность все поставить на SSD — ставьте на SSD сразу!!!
Собираете новую систему — все на SSD — сразу! Да, так будет быстрее всего!
Да, еще забыл упомянуть, что при работе с большими базами данных, экономически эффективнее часто применять ZD-XL, т.к. не вся база часто используется и хранить её всю на Flash — дороговато, а вот работать с её «горячими» областями, которые переносятся в КЭШ и размещая TempDB на томе Flash — весьма удобно.
При использовании ZD-XL база данных так и остаётся на дисковых томах в SAN. Нет необходимости что-то менять. Все, что можно сделать дополнительно — перенести TempDB на flash том ZD-XL.
Установка ZD-XL это — быстро.
1. Отключение сервера для добавления PCIe накопителя
2. Установка ПО и одна перезагрузка для поднятия драйверов и старта служб движка.
3. Помощник конкурирования (сервер уже работает и обслуживает пользователей), выбор разделения на TOМ под TempDB и КЭШ, выбор, чего ускорять, перенос TempDB на TOM Flash
4. Задание сценариев автоматизации прогрева КЭШ для выполнения аналитики или отчетов, специфических задач, тонкая оптимизация и подстройка.
Новые системы — конечно сразу нужно делать на Flash. Это максимально быстрая система.
PCIe имеет тут преимущество, т.к. задержки существенно будут меньше, чем у SATA или внешних FLASH СХД, т.к. каждое соединение FC, SAS, Ethernet — это дополнительные задержки.
Z-Drive не нуждается в КЭШ.
ZD-XL не КЭШирует запись в традиционном понимании.
Как я уже писал, ZD-XL не плотина для тракта данных, он «наблюдатель» за потоком.
На запись всегда приоритет за СХД.
Может глюк с распознаванием ID партиций.
Тут пока руками не потрогаешь — понять не получится.
Если не затруднит, будьте так любезны создать запрос в техподдержку по этому поводу.
Случай интересный и жалко будет его не передать на рассмотрение инженерам.
support.ocz.com/customer/ru/portal/emails/new
А еще лучше сделать запрос прямо из этой утилиты из раздела HELP!
Утилита скорее для обычных пользователей с одиночным SSD.
RAID или чужие драйверы обойти не реально…
Только это имеет значение.
Бэкап или реплика все равно требуется, абсолютно надежных вещей не бывает.
И описание обстоятельств выхода из строя.
support.ocz.com/customer/ru/portal/emails/new
Ушатаная NAND тут проигрывает HDD всухую.
Достаточно вспомнить, как работает NAND на запись.
Напомню…
1. Ячейку NAND нельзя перезаписать, как это происходит с магнитным доменом, который просто перемагничивается.
2. Прежде чем ячейку перезаписать, её нужно стереть, а потом еще и записать.
3. Стирание и запись в NAND существенно медленнее, чем чтение.
4. Стирание, запись и чтение ячеек всегда идут блоками, по одиночке ячейки не стирают.
Далее идут еще более сложные вещи, как выравнивание износа, сборка мусора.
Действительно, если заставлять SSD все время сбрасывать свои буферы на медию, получим 300 — 700 IOPS на запись (полная корреляция с tProg для страницы), хотя есть производители, которые просто игнорируют такие команды, причем весьма именитые…
Когда SSD защищен по питанию смысла заставлять его сбрасывать буферы после каждой операции — нет.
Просто SSD вынужден ждать пока все страницы будут записаны и только потом приступать к обработке очередной команды.
Кроме потери скорости, начинает расти WAF (Write Amplification Factor), что приводит к увеличению износа NAND.
А в SSD мы платим только за запись, так зачем платить больше?
NL SATA и прочие HDD будут «сожраны», когда разница между $/GB станет менее 2х раз, а data retention приблизится к показателю магнитной медии.
У производителей HDD есть еще несколько козырей в рукаве, а NAND пока далеко не лучшая технология для длительного хранения данных.
SAS/FC останется пока из-за поддержания вложений в инфраструктуру.
SSD же требуют своих протоколов (им ATA и SCSI как собаке — пятая нога), и скорее всего на ближайшее будущее таковым станет NVMe.
99% людей хранят «тяжёлый» и «холодный» контент на HDD или в облаке.
А для энтузиастов и серверные SSD подойдут.
Вопрос только, сколько денег за ГБ готовы отдать?
Если прям так необходимо 2 ТБ, то можно взять и серверный, хуже не будет.
Весь вопрос, а зачем в коньсьюмерщине сейчас 2ТБ и выше?
Совсем просто станет делать 2ТБ и больше после выхода нового контроллера JetExpress.
А удешевление NAND произойдет с переходом на TLC, 4LC, 8LC и т.д.
Реалистично — начало следующего года, хотя не думаю, что SSD выше 2ТБ будут иметь большой успех в потребительском сегменте.
Для простого хранения данных есть внешние HDD или облачные сервисы. Скоростей современных сетей уже достаточно для доступа практически к любому контенту.
Серия Intrepid ничего общего с потребительскими SSD не имеет, да и глюков у чипа Marvel, что-то я не припоминаю.
А количество «оленей», как Вы выражаетесь, только в России в 2014 году составило процентов эдак 20-22 в канале, и растёт.
support.ocz.com/customer/ru/portal/emails/new
Дадут инструкции, как сдать в Москве, если вдруг продавец пропал.
Были случаи на SF контроллерах, правда. Что FW лочил сразу все SSD в RAID или сразу несколько SSD, а из этого состояния выход только один — secure erase. Причем взлом FW давал возможность запустить SSD без secure erase, но таблицы все равно были затерты :(
Вот такая печалька…
Новое поколение контроллеров в этом не замечено пока :)
А еще бывают пожары, потопы и человеческий фактор, т.е. когда все накопители рядом — риск потери всего и сразу все же выше, в сравнении с методом размещения данных во множестве мест.
Это я к тому, что RAID не всемогущий, бэкап или реплика все равно необходимы. Не стоит только на RAID полагаться.
Все реально восстановить, вопрос только денег и времени… Как в любом деле — проще предотвратить беду, чем потом героически, что-то там восстанавливать. Репликация критичных данных прекрасно решает проблему. (Не RAID — эта хрень только для механики годна...) SSD как правило «цепляют простуду» коллективно, т.к. воздействие — коллективное на них.
Данные на SSD всегда хранятся вперемешку, т.е. можно сказать скремблированы, это природа SSD, её не поменять.
Понять, где, что хранится, позволяют таблицы, вот их-то потеря и вызывает видимую «смерть» SSD. (на самом деле такой SSD можно восстановить заводским методом прошивки, хотя данные будут утеряны, либо secure erase, если служебные таблицы хотя бы остались.)
Контроллеры потребительских SSD и стоковые FW под них, в силу своей простоты и дешевизны, не могут заботиться о сохранности таблиц во время внезапного пропадания питания или сбоев по питанию, от того и мрут потребительские SSD — часто и с удовольствием, если не защищены бесперебойниками.
Но ситуация — меняется, проектируются новые контроллеры (хотя дело это дорогое и не быстрое), SSD уходят от ATA команд, которые им как собаке пятая нога, писатели FW все больше уделяют внимания сохранности таблиц их дублированию или хотя бы сохранности работоспособности SSD после сбоя.
Зоопарк всевозможных «производителей» SSD сужается, всего год назад их было более 135, сейчас уже меньше 130 ;) Прогресс! Проще стандартизировать процессы и технологии.
А шифрование, только слегка подливает масла в огонь, но не является первопричиной проблемы.
Например Vector 180 — будет иметь частичную защиту главных таблиц, что позволит им как минимум остаться работоспособными, хотя есть вероятность потери данных. (В лаборатории не получилось их потерять, но уверен, что россияне найдут способ!) Очереди за ними точно не будет.
Intrepid 3600 — полная защита по питанию и RAID на N+1 на NAND, нет очередей за ними, что-то. А ведь там не Sand Force полный сюрпризов, как его не программируй…
В следующее поколение контроллеров уже будет встроен еще более продвинутый механизм защиты таблиц размещения, и контроль питания.
FW будет более продвинутой. Не все сразу, забыли как первые HDD работали?
Я бы ставил вопрос иначе — не «как мне восстановить данные?», а «что делать, что бы не потерять их»!
И как справедливо замечено ZD-XL — это решение, можно и TempDB туда положить и кэшировать, одновременно, причем кэшировать можем базы огромного размера, сотни ТБ!
Тесты CrystalMark и подобные пакеты, не способны показать всю печаль (да и делали их для маркетинга SSD), на которую обрекают себя люди, решившие использовать SSD потребительского класса в серверах или серверных нагрузках. Эти же тесты демонстрируют, что серверные SSD вообще не имеют смысла, т.к. они медленнее получаются своих потребительских собратьев по тестам CrystalMark и аналогам.
Люди не понимают, что размер тестового файла у «попсовых» пакетов — десяток, максимум сотня мегабайт. Их запускают на SSD обязательно после Secure Erase и без прекондиционирования, один раз, без достижения ssd steady state.
Их задача показать максимум, сферического коня в вакууме, а что там потом — это не важно… Как этот SSD будет работать после одной перезаписи?
Plextor M6e — это обычная попытка продать залежалые M2 хоть как-то… Результаты на запись и смешанными блоками — у него печальные… Ну не серверный это SSD…
Потестируйте настольные SSD с помощью HammerDB… hammerora.sourceforge.net/
Всё сами поймёте. Пока базу только создадите, большая часть потребительских SSD просто сдохнет либо физически, либо будет медленнее HDD…
Ну или хотя бы по SNIA… (да жёстко, но все правда вылазит, т.к. тесты делали не маркетологи, а инженеры) www.snia.org/tech_activities/standards/curr_standards/pts
Когда получите вот такой ужас: greentechreviews.ru/wp-content/uploads/2014/08/1_iops1.png
надеюсь начнёте осторожнее пользоваться CrystalMark для принятия решений, о том какой SSD ставить и куда…
Хочется хотя бы вот как-то так, или лучше greentechreviews.ru/wp-content/uploads/2014/04/iops_final.png
И вот так… greentechreviews.ru/wp-content/uploads/2014/04/saturation_final.png
А вот, что показал ZD-XL при тестах HammerDB.
ru.ocz.com/enterprise/company/news/zd-xl-tested-at-nt4admins-germany-
Вся статья на немецком, если кому захочется почитать… www.nt4admins.de/themen/applikationen/artikel/zd-xl-sql-accelerator-beschleunigt-sql-server.html
Честно говоря, не ожидал такого вопроса, да же обидно, прям как будто не читали…
ZD-XL — это когда нет возможности или желания, что-то кардинально менять в железе. Это решение для существующих систем!
Если есть возможность все поставить на SSD — ставьте на SSD сразу!!!
Собираете новую систему — все на SSD — сразу! Да, так будет быстрее всего!
Установка ZD-XL это — быстро.
1. Отключение сервера для добавления PCIe накопителя
2. Установка ПО и одна перезагрузка для поднятия драйверов и старта служб движка.
3. Помощник конкурирования (сервер уже работает и обслуживает пользователей), выбор разделения на TOМ под TempDB и КЭШ, выбор, чего ускорять, перенос TempDB на TOM Flash
4. Задание сценариев автоматизации прогрева КЭШ для выполнения аналитики или отчетов, специфических задач, тонкая оптимизация и подстройка.
Новые системы — конечно сразу нужно делать на Flash. Это максимально быстрая система.
PCIe имеет тут преимущество, т.к. задержки существенно будут меньше, чем у SATA или внешних FLASH СХД, т.к. каждое соединение FC, SAS, Ethernet — это дополнительные задержки.
ZD-XL не КЭШирует запись в традиционном понимании.
Как я уже писал, ZD-XL не плотина для тракта данных, он «наблюдатель» за потоком.
На запись всегда приоритет за СХД.