В принципе, спрос на простые, не требующие специальных навыков для установки и работы, умеющие работать локально, ассистенты определенно есть. Особенно, если удобная интеграция с ОС присутствует.
С другой стороны, хотелось бы иметь больший выбор локальных моделей:
Qwen3 (локальная 1,7В и подключаемая по API 235В)
Qwen3 1.7B, - это ни-о-чем. Но разработчики, вроде, обещают расширить список моделей.
Покупать NAS нет смысла, конечно. А вот старые NAS ими заполнять они вполне годятся.
У NVM-E SSD есть не очевидный скрытый фактор стоимости. Они сами по себе может и сравнялись с SATA SSD по стоимости, вот, только, стоимость одного порта в NAS системе на порядок выше.
Из таких дисков хорошо получаются файлопомойки в составе домашних NAS.
NAS вообще ограничены скоростью сетевого интерфейса, и на низкую скорость SATA им относительно фиолетово. SATA-III, - 6 Гигабит в секунду, сеть, - 10 гигабит (если разорились на высокую скорость). Ставить NVM-E туда вообще нет особо смысла. А, вот, заменять HDD на SSD есть.
Для портативной флешки нужна, в первую очередь, совместимость с разными устройствами. В том числе и древними. Носить с собой в кармане флешку из 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.
В принципе, спрос на простые, не требующие специальных навыков для установки и работы, умеющие работать локально, ассистенты определенно есть. Особенно, если удобная интеграция с ОС присутствует.
С другой стороны, хотелось бы иметь больший выбор локальных моделей:
Qwen3 1.7B, - это ни-о-чем. Но разработчики, вроде, обещают расширить список моделей.
Покупать NAS нет смысла, конечно. А вот старые NAS ими заполнять они вполне годятся.
У NVM-E SSD есть не очевидный скрытый фактор стоимости. Они сами по себе может и сравнялись с SATA SSD по стоимости, вот, только, стоимость одного порта в NAS системе на порядок выше.
Из таких дисков хорошо получаются файлопомойки в составе домашних NAS.
NAS вообще ограничены скоростью сетевого интерфейса, и на низкую скорость SATA им относительно фиолетово. SATA-III, - 6 Гигабит в секунду, сеть, - 10 гигабит (если разорились на высокую скорость). Ставить NVM-E туда вообще нет особо смысла. А, вот, заменять HDD на SSD есть.
Для портативной флешки нужна, в первую очередь, совместимость с разными устройствами. В том числе и древними. Носить с собой в кармане флешку из 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?