Для портативной флешки нужна, в первую очередь, совместимость с разными устройствами. В том числе и древними. Носить с собой в кармане флешку из 2025-ого года которая работает только в новых компах 2025-ого года (но не работает в любом компе древнее 2024-ого без драйвера, а на совсем древних и драйвера то нет) можно только "для понтов". Это неудобно.
А делать такую флешку из SSD первого эшелона имеет смысл, как раз, для надежности.
Еще один рабочий юзкейз, - это продление жизни и срока эксплуатации старых СХД. Замена HDD на свежие SSD (в том числе консьюмерские) в старых СХД (при условии, что они умеют обращаться с SATA SSD) может серьезно увеличить производительность системы в сравнении с HDD (до десятков раз). И, при условии достаточности ресурса записи, может отложить апгрейд остального железа годка на 3-4.
Самое интересное, что предоставлять данные родственников без их непосредственного на то согласия является нарушением закона о защите ПД в большинстве юрисдикций, для которых действует ESTA.
Так что, интересно, как они обходят этот момент с точки зрения законов других стран.
Сейчас да. Однако, до сих пор, M.2 SATA накопители являлись самым простым способом сделать надежный внешний накопитель, который работает практически в любой ОС, даже если ей уже 10-15 лет.
Все дело в том, что микросхемы SATA => USB вылизаны годами, и, имеют хорошую совместимость со старым железом, даже тем, что не умеет USB 3.0.
В сравнении с этим, с точки зрения совместимости, современные NVM-E => USB адаптеры, это хождение по граблям.
Пузыри и венчурные инвестиции, это не баг, а фича, которая позволяет государству финансировать инновации и инфраструктуру за счет частного капитала (и пенсионных сбережений) при этом, не неся никаких рисков, т.к. инвесторы и пенсионеры свято верят, что виновато не государство, а они сами, потому что вложились не туда (прямые инвестиции или частный пенсионный фонд).
При этом, когда пузырь лопается, созданные технологии и инфраструктура никуда не пропадают, и, могут после банкротства/схлопывания быть выкуплены другим, более прибыльным бизнесом задешево, и, успешно эксплуатироваться.
Достаточно взять размер значения (value) больше двукратного размера страницы кэша ЦП. Все бонусы от особенностей работы префетчера и кэша ЦП на open addressed linear probing будут утеряны. Ну, и, взять таблицу, которая не помещается к кэш ЦП целиком.
В общем случае, - да, но для частного случая с маленьким размером ключ+значение все же будет медленнее раза в полтора-два при большом размере таблицы. Просто потому, что на больших таблицах узкое место, - случайный доступ в память. И, у подобной простой реализации он будет только один. А у swiss table, - два (отдельно в блок хэшей и в блок ключей+значений).
Вроде там автор для решения проблемы придумал инвертируемый хэш (1:1 отображение). Однако, решение крайне спорное, как и выбор размера таблицы по степеням двойки вместо простых чисел с использованием маски вместо остатка от деления.
Да, метод цепочек еще проще в реализации, и, часто эффективнее, если размеры ключа/значения достаточно велики.
А, если пара ключ+значение укладываются хотя бы в половину-четверть длины строки кэша, то открытая адресация с линейным зондированием обычно выигрывают.
По смыслу, - сама идея таблицы с открытой (или, сплошной, как её еще называют в русской литературе по алгоритмам) адресацией и линейным зондированием действительно хороша, и, на современных архитектурах ЦП показывает себя намного лучше многих других вариантов. Однако, реализация излишне усложнена. Можно сделать гораздо проще, и, не менее быстро.
с другой стороны - проблему частично сгладит невысокая вероятность попадания на большом количестве дисков.
Если дисков должно быть 10 штук, то, каждый 10ый случайный запрос будет попадать в отсутствующий диск, и превращаться 9 запросов на оставшиеся вместо одного. Так что, при увеличении IOPS верхний предел IOPS при случайном чтении все равно будет стремиться к скорости одного диска.
Практика показывает что он никому ничего не должен.
Впрочем никогда не проверял диски на исправность перед перезагрузкой.
Я тоже не проверял. Они вытаскиваются из корзины по факту вываливания из массива. В момент перезагрузки их в системе нет, т.к. замена диска перезагрузки не требует.
С чего бы вдруг by design?
Если диски присутствуют не все, то, операция чтения с отсутствующего диска требует прочитать данные со всех остальных и вычислить четность. Производительность чтения падает со значений сравнимых с raid0 (в IOPS) до скорости самого медленного диска. Запись у raid 5/6 всегда на все диски идет и всегда меньше или равна скорости самого медленно диска (в IOPS). Это вправило верно почти всегда, за исключением случая чисто линейной записи когда все блоки обновляются синхронно на всех дисках, и, узким местом становится не IOPS (что верно почти всегда в реальных сценариях), а скорость интерфейса/чтения с пластины.
исключение самого медленного (сдыхающего) ускорит ситуацию
При настроенном ERC "сдыхающий" должен сам из массива отвалиться и быть заменен. Так что, такие диски, - синоним неисправных.
А на raid контроллерах железо не выросло? У нас в основном линейное чтение/запись, может я не замечаю что все ужасно.
Выросло. Но, раньше, узкоспециализированное железо могло это делать лучше, чем железо общего назначения. А, сейчас, почти все RAID контроллеры представляют собой какой-нибудь слегка кастомизированный ARM/PowerPC/x86 SoC, который внутри имеет свою операционную систему, вплоть до специализированной сборки Linux, которая внутри собирает программные массивы :-D. Да они стали быстрее, но, чтобы разогнать SoC до 5ти гигагерц на него надо ставить огромный радиатор, как на процессоре/видеокарте, и подводить Ватт этак 100 по питанию.
Сейчас TDP является узким местом всей электроники. А, радиатор у вас на ЦП всяко больше размером чем на RAID карточке.
И да. Чисто линейное чтение/запись очень узкоспециализированный сценарий со своими особенностями.
Любой RAID, который повышает отказоустойчивость, все равно лучше, чем его полное отсутствие. Так что, тут я вынужден согласиться, что для всего есть свои применения. Для таких сценариев что-то более сложное, действительно, не нужно.
fake-RAID, это вообще зло. Они сочетают в себе недостатки обоих (аппаратных и программных) RAID, притом не имеют никаких достоинств в сравнении с любым из них, кроме цены, которая сейчас равна почти нулю.
Но, и, к сожалению, многие "аппаратные" сейчас де-факто являются "перекачанными программными". То есть, вся RAID логика де-факто делается на CPU посредством программной прослойки, которая загружается через BIOS контроллера или драйвер.
Такое, теоретически, возможно, если носитель поврежден и оставлен в системе в момент перезагрузки. В редких случаях может сбоить BIOS POST или попытки чтения загрузочной области. Но, я ни разу не перезагружался с неисправным диском в системе. Просто, из корзины его достаю перед этим, или сразу меняю, потому, ни разу не сталкивался.
Вообще, отказ диска, - это ситуация штатная, перезагрузки для замены не требующая. Если, конечно, у вас не аппаратный контролер, которому надо в BIOS залезть, чтобы массив пересобрать, потому что в ОС нет под него софта.
Ну, а, тормоза, - это ожидаемо. Некоторые уровни RAID тормозят при деградации by design (5-6), зеркало тоже уменьшит скорость из-за потери диска, а, чередование, вообще протухнет. И, аппаратный raid тут ничем не поможет.
А, чтобы, умирающий, но еще пока не совсем мертвый диск не тормозил систему, надо просто настроить SCT ERC. Ну, или переплачивать за "диски для RAID" где по-умолчанию ERC включен, хотя, настроить/включить его можно и на большинстве обычных дисков.
Еще, замечу, что, к сожалению, производительность у аппаратных рэйдов в последние годы, сначала, сравнялась с программными, а потом, начала, отставать. Особенно заметно на NVM-E SSD. Там у аппаратных RAID задержки, а, следовательно, однопоточный IOPS сильно проседает. Просто из за дополнительной обработки данных контроллером, которая требует время. Ну и железо процессорное сильно выросло в производительности. Больше нет узких мест в RAM/CPU/PCI-E. Ну, если их, конечно, своими руками не создать, забыв сконфигурировать размер кэша программного массива, или повесив десяток дисков на контроллер воткнутый в 1xPCI-E слот.
У меня все SSD из среднего сегмента, тоже бытовые, и, одного производителя. Зоопарка нет, всего 2 разные модели SATA и 2 модели NVM-E используются в разных массивах. Выборка очень не репрезентативная. Производитель samsung.
Я держу пару достаточно крупных массивов на SSD (как NVM-E, так и SATA). Из моего опыта: они действительно отъезжают внезапно, но, обычно, при этом, сваливаются в readonly и просто вываливаются из массива. И, восстановление банальным dd на новый носитель + re-add прокатывало во всех случаях. Полных смертей не было пока. Но, они, конечно, возможны, как и у дисков.
Единственно, я начал, на всякий случай, использовать raid6 и raid1 с тремя зеркалами для совсем уж критичных данных. Но, как показала практика, все оказалось даже проще, чем с дисками.
Могу только прокомментировать, что, с такими ценами на HDD за 1TB проще уже на SDD 2TB накопители переходить. Цены почти сравнялись в пересчете на терабайт. Правда, это, конечно, не для всех сценариев подойдет. Если надо много писать, то нужно учитывать TBW ресурс.
Только, еще замечу, что за пределами РФ диски аналогично сильно подорожали. Так что, это, скорее, AI гонка все же виновата)
Дважды попадал на такое. Один раз отлетел контроллер, а замену уже просто не найти. Пришлось осваивать программные средства восстановления данных на RAID массивах из образов дисков. Я, тогда, возблагодарил всех богов, что держал встроенный в контроллер кэш в режиме write-through. Успешно.
Второй раз отлетели процессор и материнская плата на сервере. Контроллер вроде бы вот он, даже рабочий, но, PCI, и втыкать на новом железе его уже некуда. И, вроде, есть переходники с PCI-E, но, нет драйвера под новую ОС. А в старой нет драйвера на новый процессор :-)
Благо, навыки восстановления данных уже имелись :-)
Для портативной флешки нужна, в первую очередь, совместимость с разными устройствами. В том числе и древними. Носить с собой в кармане флешку из 2025-ого года которая работает только в новых компах 2025-ого года (но не работает в любом компе древнее 2024-ого без драйвера, а на совсем древних и драйвера то нет) можно только "для понтов". Это неудобно.
А делать такую флешку из SSD первого эшелона имеет смысл, как раз, для надежности.
Еще один рабочий юзкейз, - это продление жизни и срока эксплуатации старых СХД. Замена HDD на свежие SSD (в том числе консьюмерские) в старых СХД (при условии, что они умеют обращаться с SATA SSD) может серьезно увеличить производительность системы в сравнении с HDD (до десятков раз). И, при условии достаточности ресурса записи, может отложить апгрейд остального железа годка на 3-4.
Самое интересное, что предоставлять данные родственников без их непосредственного на то согласия является нарушением закона о защите ПД в большинстве юрисдикций, для которых действует ESTA.
Так что, интересно, как они обходят этот момент с точки зрения законов других стран.
Сейчас да. Однако, до сих пор, M.2 SATA накопители являлись самым простым способом сделать надежный внешний накопитель, который работает практически в любой ОС, даже если ей уже 10-15 лет.
Все дело в том, что микросхемы SATA => USB вылизаны годами, и, имеют хорошую совместимость со старым железом, даже тем, что не умеет USB 3.0.
В сравнении с этим, с точки зрения совместимости, современные NVM-E => USB адаптеры, это хождение по граблям.
Пузыри и венчурные инвестиции, это не баг, а фича, которая позволяет государству финансировать инновации и инфраструктуру за счет частного капитала (и пенсионных сбережений) при этом, не неся никаких рисков, т.к. инвесторы и пенсионеры свято верят, что виновато не государство, а они сами, потому что вложились не туда (прямые инвестиции или частный пенсионный фонд).
При этом, когда пузырь лопается, созданные технологии и инфраструктура никуда не пропадают, и, могут после банкротства/схлопывания быть выкуплены другим, более прибыльным бизнесом задешево, и, успешно эксплуатироваться.
Достаточно взять размер значения (value) больше двукратного размера страницы кэша ЦП. Все бонусы от особенностей работы префетчера и кэша ЦП на open addressed linear probing будут утеряны. Ну, и, взять таблицу, которая не помещается к кэш ЦП целиком.
В общем случае, - да, но для частного случая с маленьким размером ключ+значение все же будет медленнее раза в полтора-два при большом размере таблицы. Просто потому, что на больших таблицах узкое место, - случайный доступ в память. И, у подобной простой реализации он будет только один. А у swiss table, - два (отдельно в блок хэшей и в блок ключей+значений).
Вроде там автор для решения проблемы придумал инвертируемый хэш (1:1 отображение). Однако, решение крайне спорное, как и выбор размера таблицы по степеням двойки вместо простых чисел с использованием маски вместо остатка от деления.
Да, метод цепочек еще проще в реализации, и, часто эффективнее, если размеры ключа/значения достаточно велики.
А, если пара ключ+значение укладываются хотя бы в половину-четверть длины строки кэша, то открытая адресация с линейным зондированием обычно выигрывают.
По переводу, - терминология хромает.
По смыслу, - сама идея таблицы с открытой (или, сплошной, как её еще называют в русской литературе по алгоритмам) адресацией и линейным зондированием действительно хороша, и, на современных архитектурах ЦП показывает себя намного лучше многих других вариантов. Однако, реализация излишне усложнена. Можно сделать гораздо проще, и, не менее быстро.
Если дисков должно быть 10 штук, то, каждый 10ый случайный запрос будет попадать в отсутствующий диск, и превращаться 9 запросов на оставшиеся вместо одного. Так что, при увеличении IOPS верхний предел IOPS при случайном чтении все равно будет стремиться к скорости одного диска.
Да. Такое тоже бывает. Но реже.
Я тоже не проверял. Они вытаскиваются из корзины по факту вываливания из массива. В момент перезагрузки их в системе нет, т.к. замена диска перезагрузки не требует.
Если диски присутствуют не все, то, операция чтения с отсутствующего диска требует прочитать данные со всех остальных и вычислить четность. Производительность чтения падает со значений сравнимых с raid0 (в IOPS) до скорости самого медленного диска. Запись у raid 5/6 всегда на все диски идет и всегда меньше или равна скорости самого медленно диска (в IOPS). Это вправило верно почти всегда, за исключением случая чисто линейной записи когда все блоки обновляются синхронно на всех дисках, и, узким местом становится не IOPS (что верно почти всегда в реальных сценариях), а скорость интерфейса/чтения с пластины.
При настроенном ERC "сдыхающий" должен сам из массива отвалиться и быть заменен. Так что, такие диски, - синоним неисправных.
Выросло. Но, раньше, узкоспециализированное железо могло это делать лучше, чем железо общего назначения. А, сейчас, почти все RAID контроллеры представляют собой какой-нибудь слегка кастомизированный ARM/PowerPC/x86 SoC, который внутри имеет свою операционную систему, вплоть до специализированной сборки Linux, которая внутри собирает программные массивы :-D. Да они стали быстрее, но, чтобы разогнать SoC до 5ти гигагерц на него надо ставить огромный радиатор, как на процессоре/видеокарте, и подводить Ватт этак 100 по питанию.
Сейчас TDP является узким местом всей электроники. А, радиатор у вас на ЦП всяко больше размером чем на RAID карточке.
И да. Чисто линейное чтение/запись очень узкоспециализированный сценарий со своими особенностями.
Любой RAID, который повышает отказоустойчивость, все равно лучше, чем его полное отсутствие. Так что, тут я вынужден согласиться, что для всего есть свои применения. Для таких сценариев что-то более сложное, действительно, не нужно.
fake-RAID, это вообще зло. Они сочетают в себе недостатки обоих (аппаратных и программных) RAID, притом не имеют никаких достоинств в сравнении с любым из них, кроме цены, которая сейчас равна почти нулю.
Но, и, к сожалению, многие "аппаратные" сейчас де-факто являются "перекачанными программными". То есть, вся RAID логика де-факто делается на CPU посредством программной прослойки, которая загружается через BIOS контроллера или драйвер.
Такое, теоретически, возможно, если носитель поврежден и оставлен в системе в момент перезагрузки. В редких случаях может сбоить BIOS POST или попытки чтения загрузочной области. Но, я ни разу не перезагружался с неисправным диском в системе. Просто, из корзины его достаю перед этим, или сразу меняю, потому, ни разу не сталкивался.
Вообще, отказ диска, - это ситуация штатная, перезагрузки для замены не требующая. Если, конечно, у вас не аппаратный контролер, которому надо в BIOS залезть, чтобы массив пересобрать, потому что в ОС нет под него софта.
Ну, а, тормоза, - это ожидаемо. Некоторые уровни RAID тормозят при деградации by design (5-6), зеркало тоже уменьшит скорость из-за потери диска, а, чередование, вообще протухнет. И, аппаратный raid тут ничем не поможет.
А, чтобы, умирающий, но еще пока не совсем мертвый диск не тормозил систему, надо просто настроить SCT ERC. Ну, или переплачивать за "диски для RAID" где по-умолчанию ERC включен, хотя, настроить/включить его можно и на большинстве обычных дисков.
Еще, замечу, что, к сожалению, производительность у аппаратных рэйдов в последние годы, сначала, сравнялась с программными, а потом, начала, отставать. Особенно заметно на NVM-E SSD. Там у аппаратных RAID задержки, а, следовательно, однопоточный IOPS сильно проседает. Просто из за дополнительной обработки данных контроллером, которая требует время. Ну и железо процессорное сильно выросло в производительности. Больше нет узких мест в RAM/CPU/PCI-E. Ну, если их, конечно, своими руками не создать, забыв сконфигурировать размер кэша программного массива, или повесив десяток дисков на контроллер воткнутый в 1xPCI-E слот.
У меня все SSD из среднего сегмента, тоже бытовые, и, одного производителя. Зоопарка нет, всего 2 разные модели SATA и 2 модели NVM-E используются в разных массивах. Выборка очень не репрезентативная. Производитель samsung.
Я думаю, это просто старые заморочки оставшиеся от аппаратных рэйдов. Там все диски надо было одного размера и, желательно, конфигурации.
Программным рэйдам на это давно уже все равно.
Интересно, есть ли какая открытая статистика по-типу BackBlaze, но про SSD?
Я держу пару достаточно крупных массивов на SSD (как NVM-E, так и SATA). Из моего опыта: они действительно отъезжают внезапно, но, обычно, при этом, сваливаются в readonly и просто вываливаются из массива. И, восстановление банальным dd на новый носитель + re-add прокатывало во всех случаях. Полных смертей не было пока. Но, они, конечно, возможны, как и у дисков.
Единственно, я начал, на всякий случай, использовать raid6 и raid1 с тремя зеркалами для совсем уж критичных данных. Но, как показала практика, все оказалось даже проще, чем с дисками.
Могу только прокомментировать, что, с такими ценами на HDD за 1TB проще уже на SDD 2TB накопители переходить. Цены почти сравнялись в пересчете на терабайт. Правда, это, конечно, не для всех сценариев подойдет. Если надо много писать, то нужно учитывать TBW ресурс.
Только, еще замечу, что за пределами РФ диски аналогично сильно подорожали. Так что, это, скорее, AI гонка все же виновата)
+100500
Дважды попадал на такое. Один раз отлетел контроллер, а замену уже просто не найти. Пришлось осваивать программные средства восстановления данных на RAID массивах из образов дисков. Я, тогда, возблагодарил всех богов, что держал встроенный в контроллер кэш в режиме write-through. Успешно.
Второй раз отлетели процессор и материнская плата на сервере. Контроллер вроде бы вот он, даже рабочий, но, PCI, и втыкать на новом железе его уже некуда. И, вроде, есть переходники с PCI-E, но, нет драйвера под новую ОС. А в старой нет драйвера на новый процессор :-)
Благо, навыки восстановления данных уже имелись :-)
С тех пор, программные массивы, - наше все.