Comments 39
1. ваши «сегменты» всю жизнь назывались секторами
2. ранние SCSI диски исторически имели независимые приводы головок
Неужели вы думаете, что разработчики жестких дисков такие наивные, что не отрабатывали подобные варианты? С увеличением числа движущихся частей растет количество отказов и стоимость изготовления.
Вместо изобретения велосипедов, я бы посоветовал почитать историю развития этого чуда техники и соответствующих решений.
2. ранние SCSI диски исторически имели независимые приводы головок
Неужели вы думаете, что разработчики жестких дисков такие наивные, что не отрабатывали подобные варианты? С увеличением числа движущихся частей растет количество отказов и стоимость изготовления.
Вместо изобретения велосипедов, я бы посоветовал почитать историю развития этого чуда техники и соответствующих решений.
1. согласен
2. не согласен, ранние SCSI диски были на сервоприводах, весьма сомневаюсь что там на одной поверхности работали одновременно две рабочих головки в силу сложности точного позиционирования. В случае сбоя позиционирования: необходимо либо выставлять на 0 дорожку, либо полностью переформатировать диск, с потерей всех данных.
Современнай конструкция позволяет по силе считываемого сигнала выставить головку не по шагу сервопривода, а по силе считываемого сигнала.
идея в том, чтобы на одной поверхности работали одновременно две и более рабочих головки, на нескольких коромыслах в разных частях диска.
в силу инертности мышления, могли просто и не попробовать,
есть байка про то как на самолетах появилось два «магнето» что сильно увеличило надежность самолетов (а ведь это увеличение количества частей).
2. не согласен, ранние SCSI диски были на сервоприводах, весьма сомневаюсь что там на одной поверхности работали одновременно две рабочих головки в силу сложности точного позиционирования. В случае сбоя позиционирования: необходимо либо выставлять на 0 дорожку, либо полностью переформатировать диск, с потерей всех данных.
Современнай конструкция позволяет по силе считываемого сигнала выставить головку не по шагу сервопривода, а по силе считываемого сигнала.
идея в том, чтобы на одной поверхности работали одновременно две и более рабочих головки, на нескольких коромыслах в разных частях диска.
в силу инертности мышления, могли просто и не попробовать,
есть байка про то как на самолетах появилось два «магнето» что сильно увеличило надежность самолетов (а ведь это увеличение количества частей).
добрался до дома, раскопал свою книжку: Джон Гудмэн «Секреты жесткого диска» изд. Киев 1994 года
угадайте что с тех пор кардинально изменилось в жестких дисках?
угадайте что с тех пор кардинально изменилось в жестких дисках?
Который из сотен патентов назвать-то? Тут и перпендикулярная запись и запись с подогревом и туева хуча изменений в системах кодирования и восстановления ошибок. Не говоря про периферийные интерфейсы и геометрию.
Раньше в машинах автомагнитолы не было, а после того как в машину внедрили автомагнитолу, это стало принципиально другое устройство.
Я спрашиваю про принципиальную разницу, методы кодирования вообще от связистов могло прилететь, с магнитооптикой я лично в 2000-х познакомился, жутко дорогой привод и носитель, диск есть а считать не на чем, вики говорит что в 80-х. уже появилась технология.
Пока я не вижу что кто-то пробовал такое сделать, сюда опубликовал с надеждой что кто-то где-то читал, слышал, а может и сам делал.
Чуть ниже видео прицепили, сначала подумал что чувак из двух старых дисков реализовал то что я думал, однако он разобрал старый SCSI диск который тупо позволял сделать два разных запроса к двум разным областям (почти как два жестких диска но с одним шпинделем и одним интерфейсом). Моя же идея позволит удвоить IOPS на одном наборе данных.
Я спрашиваю про принципиальную разницу, методы кодирования вообще от связистов могло прилететь, с магнитооптикой я лично в 2000-х познакомился, жутко дорогой привод и носитель, диск есть а считать не на чем, вики говорит что в 80-х. уже появилась технология.
Пока я не вижу что кто-то пробовал такое сделать, сюда опубликовал с надеждой что кто-то где-то читал, слышал, а может и сам делал.
Чуть ниже видео прицепили, сначала подумал что чувак из двух старых дисков реализовал то что я думал, однако он разобрал старый SCSI диск который тупо позволял сделать два разных запроса к двум разным областям (почти как два жестких диска но с одним шпинделем и одним интерфейсом). Моя же идея позволит удвоить IOPS на одном наборе данных.
Всё это сделать можно но:
1. Значительно увеличит стоимость диска, повысит шанс что головки упадут на диск и запилят блины на 50%
2. Данные и так уже давно пишутся на обе поверхности диска. В итоге это уменьшит доступный объём диска, но стоимость оставит туже, однако никак не защити от проблем шпинделя, контроллера и выхода из строя целиком всего блока головок.
3. Процессор куда быстрей построит цепочки FAT чем диск, это во первых, во вторых файловых систем много не спроста, и ограничивать себя одной смысла нету.
1. Значительно увеличит стоимость диска, повысит шанс что головки упадут на диск и запилят блины на 50%
2. Данные и так уже давно пишутся на обе поверхности диска. В итоге это уменьшит доступный объём диска, но стоимость оставит туже, однако никак не защити от проблем шпинделя, контроллера и выхода из строя целиком всего блока головок.
3. Процессор куда быстрей построит цепочки FAT чем диск, это во первых, во вторых файловых систем много не спроста, и ограничивать себя одной смысла нету.
1 вероятность рассчитывается не так просто,
2. речь идет не о том что «оказывается писать можно на двух сторонах», об этом известно еще со времен флопповодов, речь идет о распределении даных по принципу RAID системы, но не между физическими устройствами, а на разных поверхностях, на одной из них пишется «контрольная сумма» остальных даных с других поверхностей.
3. FAT32 позволяет организовать цепочку почти в 16 Гб, если есть место в оперативной памяти хранить 16 Гб, то да, согласен процессор быстрее просчитает, в противном случае контроллер диска узнает минимум на 5 мкс быстрее где следующий кластер.
файловых систем много: наследие, новые вызовы по объемам, разное поведение на разных ситуациях и на разных носителях. ну и «патенты».
2. речь идет не о том что «оказывается писать можно на двух сторонах», об этом известно еще со времен флопповодов, речь идет о распределении даных по принципу RAID системы, но не между физическими устройствами, а на разных поверхностях, на одной из них пишется «контрольная сумма» остальных даных с других поверхностей.
3. FAT32 позволяет организовать цепочку почти в 16 Гб, если есть место в оперативной памяти хранить 16 Гб, то да, согласен процессор быстрее просчитает, в противном случае контроллер диска узнает минимум на 5 мкс быстрее где следующий кластер.
файловых систем много: наследие, новые вызовы по объемам, разное поведение на разных ситуациях и на разных носителях. ну и «патенты».
2. Вы потеряете объём одной стороны одного диска, допустим их было 2 блина по 1Tb каждый. Итого у вас диск превратится из диска на 2Tb в диск на 1.5Tb и теперь он способен пережить сметь одной головки. Но стоить он продолжил как 2Tb а надежность ну про неё трудно сказать насколько она выросла. Плюс диск теперь вынужден делать больше операций записи что скажется на их скорости.
3. А в реальности какие обычно цепочки на переносных дисках с FAT32? И сколько памяти нужно для их хранения?
3. А в реальности какие обычно цепочки на переносных дисках с FAT32? И сколько памяти нужно для их хранения?
2. выросла надежность хранения данных, за счет сокращения объема хранения данных, тут уже нужна статистика как часто встречается ситуация повреждения 1 сектора в последовательности из 4-5 (если хранить данные на одной дорожке). что касается записи:
-ситуация когда можно писать одновременно на все дорожки маловероятна, но реальна.
-рассмотрим более вероятную ситуацию, когда запись идет последовательно, и между процедур записи необходимо заложить время необходимое для доводки следующей головки точно по дорожке. тут уже нужно резюме людей кто занимается разработкой и изготовлением HDD. Samsung, Hitachi, WD, Seagate, есть тут кто в правило 6 рукопожатий уложиться до инженеров?
3. для 2 гб файла (предел фат32) и 64 кб в вырожденном случае составит:
2Гб/64кб=32768 транзакций передачи данных по 64 кб около 3 секунд
при 4 кб кластере получиться 524288 транзакций примерно те-же 3 секунды
в реальности конечно вырожденные случаи редки, но сам факт того если при обработке данных мы можем сэкономить 3 секунды, стоит задуматься.
-ситуация когда можно писать одновременно на все дорожки маловероятна, но реальна.
-рассмотрим более вероятную ситуацию, когда запись идет последовательно, и между процедур записи необходимо заложить время необходимое для доводки следующей головки точно по дорожке. тут уже нужно резюме людей кто занимается разработкой и изготовлением HDD. Samsung, Hitachi, WD, Seagate, есть тут кто в правило 6 рукопожатий уложиться до инженеров?
3. для 2 гб файла (предел фат32) и 64 кб в вырожденном случае составит:
2Гб/64кб=32768 транзакций передачи данных по 64 кб около 3 секунд
при 4 кб кластере получиться 524288 транзакций примерно те-же 3 секунды
в реальности конечно вырожденные случаи редки, но сам факт того если при обработке данных мы можем сэкономить 3 секунды, стоит задуматься.
Свою первую нелепую идею в «крупном масштабе» можете лицезреть в обзоре от Дейва.
На весь «четвертьлямобаксовый» хард два независимых блока головок по 2 головки на сторону.
Как итог — это уже придумали до вас.
Вторая нелепая идея разбивается о выход из строя диска целиком. Сдох контроллер — как восстановить данные? Посыпался диск — посыпался весь — кто будет восстанавливать данные? Я просто выкину нерабочий диск и воткну рабочий и запущу процедуру восстановления массива с других отдельных хардов. В отличие от харда из видео в современных хардах нельзя просто так взять иборомирзаменить посыпавшуюся пластину или головку. И делать это никто, кроме МАК не будет. Последним просто по роду деятельности приходится этим заниматься.
Третья нелепая идея утыкается на ворох файловых систем (комикс xkcd о стандартах). В итоге для одних ФС надо будет покупать одни харды, для других — другие. Универсальность? нет, не слышал. Мне сложно представить контроллер для харда, поддерживающий все вышедшие и невышедшие файловые системы. Только если этот контроллер не мини-компьютер. Менять прошивку? А если поддержка закончилась? Менять всю СХД целиком? Нет уж. Делегирование функций штука полезная, но только тогда, когда это приносит пользу.
На весь «четвертьлямобаксовый» хард два независимых блока головок по 2 головки на сторону.
Как итог — это уже придумали до вас.
Вторая нелепая идея разбивается о выход из строя диска целиком. Сдох контроллер — как восстановить данные? Посыпался диск — посыпался весь — кто будет восстанавливать данные? Я просто выкину нерабочий диск и воткну рабочий и запущу процедуру восстановления массива с других отдельных хардов. В отличие от харда из видео в современных хардах нельзя просто так взять и
Третья нелепая идея утыкается на ворох файловых систем (комикс xkcd о стандартах). В итоге для одних ФС надо будет покупать одни харды, для других — другие. Универсальность? нет, не слышал. Мне сложно представить контроллер для харда, поддерживающий все вышедшие и невышедшие файловые системы. Только если этот контроллер не мини-компьютер. Менять прошивку? А если поддержка закончилась? Менять всю СХД целиком? Нет уж. Делегирование функций штука полезная, но только тогда, когда это приносит пользу.
классическая схема, с тем изменением что можно посылать два запроса в разные части диска, но нельзя сделать два запроса к одному
смотрел видео в надежде что начну спать спокойно, но пока нет.
добавил картинку для пояснения, что я имел в виду.
одним из вариантов реализации было разработка языка с помощью которого можно описать файловую систему, пример тому SQL, вы можете использовать разные сервера баз данных, но все сервера поддерживающие SQL вернут вам идентичный (в теории) ответ на одном наборе даных
смотрел видео в надежде что начну спать спокойно, но пока нет.
добавил картинку для пояснения, что я имел в виду.
одним из вариантов реализации было разработка языка с помощью которого можно описать файловую систему, пример тому SQL, вы можете использовать разные сервера баз данных, но все сервера поддерживающие SQL вернут вам идентичный (в теории) ответ на одном наборе даных
Уже есть: Жесткий диск Kinetic для масштабируемой объектной системы хранения данных
API это файловая система и даже больше.
Первый в мире жесткий диск с интерфейсом Ethernet и поддержкой API с открытым исходным кодом, разработанный специально для сверхмасштабируемых и горизонтально масштабируемых сред. Seagate Kinetic HDD упрощает процесс создания программных и аппаратных архитектур хранения данных, снижая совокупную стоимость владения (ТСО) и позволяя оперативно реагировать на растущие потребности облачной инфраструктуры систем хранения данных.
API это файловая система и даже больше.
да простят меня дизайнеры нарисовавшие исходное изображение, но что попалось первым.
Про сектора уже вспомнили, так что прицеплюсь к другому.
А собственно, КАК жёсткий диск (контроллер) должен знать, где находится какой сектор и какое положение шпинделя (угловое) в текущий момент? Ответ: А никак. Если таблица секторов ещё помещается в память контроллера (все помнят, что с переходом на LBA, одинаковое количество секторов на цинидр перестало быть одинаковым? (На самом деле — даже несколько раньше)).
Так вот. Контроллер жёсткого диска приблизительно знает, где искать нужный сектор (плюс, опять же, информация о переразмещённых секторах) и располагает головки над определённым цинидром. Да, процедура не столь быстрая (хотя и вполне шустро происходит), но механика есть механика, и иногда головка пролетает дальше, или же не долетает до нужного. Как узнать? По сервометкам на диске. Из них же получаются и номера секторов под головкой. А уж потом происходит коррекция, или ожидание сектора.
Так что, изготовить несколько блоков головок — технически возможно. Но бесполезно. Из этого мало чего можно выиграть сейчас. Особенно, для жёстких дисков с приличным размером КЭШ памяти.
А собственно, КАК жёсткий диск (контроллер) должен знать, где находится какой сектор и какое положение шпинделя (угловое) в текущий момент? Ответ: А никак. Если таблица секторов ещё помещается в память контроллера (все помнят, что с переходом на LBA, одинаковое количество секторов на цинидр перестало быть одинаковым? (На самом деле — даже несколько раньше)).
Так вот. Контроллер жёсткого диска приблизительно знает, где искать нужный сектор (плюс, опять же, информация о переразмещённых секторах) и располагает головки над определённым цинидром. Да, процедура не столь быстрая (хотя и вполне шустро происходит), но механика есть механика, и иногда головка пролетает дальше, или же не долетает до нужного. Как узнать? По сервометкам на диске. Из них же получаются и номера секторов под головкой. А уж потом происходит коррекция, или ожидание сектора.
Так что, изготовить несколько блоков головок — технически возможно. Но бесполезно. Из этого мало чего можно выиграть сейчас. Особенно, для жёстких дисков с приличным размером КЭШ памяти.
Для целей считывания/записи одновременно двух секторов одного цилиндра — смысла нет. Но для разных цилиндров таки есть, поскольку экономится время позиционирования. Ну и скорость передачи данных будет больше в два раза, хоть и ценой двукратного увеличения стоимости, но зато в одном корпусе.
Одинаковое количество секторов на дорожке никак не связано с внедрением LBA, LBA (для IDE) разработано тогда, когда объем диска пришел к пределу классической адресации CHS (там уже пошли в разброд кто в лес кто по дрова) и по началу запросы CHS транслировались в свою адресацию.
Тот же SCSI изначально был ориентирован на LBA.
Тот же SCSI изначально был ориентирован на LBA.
откуда инжекторный двигатель сгорания знает в какой момент нужно на определенную свечу подать электрический импульс?
контроллер основываясь на информации, какой период занял предыдущий оборот двигателя, он рассчитывает в какой момент ему нужно подать зажигание.
Вычислить где должен (по идее) находиться сектор вопрос чистой математики.
Удвоение IOPS для вас не показатель? Что касается приличного объема КЭШ памяти, все хорошо пока объем данных вписывается в рамки кэша и объема основной оперативной памяти. Скопируйте 2 терабайта при чем задом наперед
PS промахнулся к AlanDrakes
контроллер основываясь на информации, какой период занял предыдущий оборот двигателя, он рассчитывает в какой момент ему нужно подать зажигание.
Вычислить где должен (по идее) находиться сектор вопрос чистой математики.
Удвоение IOPS для вас не показатель? Что касается приличного объема КЭШ памяти, все хорошо пока объем данных вписывается в рамки кэша и объема основной оперативной памяти. Скопируйте 2 терабайта при чем задом наперед
PS промахнулся к AlanDrakes
про 1 — круто но дорого, потому как увеличение сложности в два раза увеличить скорость в лучшем случае тоже в два раза (а в среднем небось квадратный корень из количества головок). Полагаю конечному потребителю эффективней купить несколько дисков с одной головкой (и так же увеличить себе скорость случайного доступа) чем увеличивать стоимость железок без увеличения их суммарной емкости!
про 3 — а разве серверные NAS-ы не являтся тем о чем вы пишете, но с большей гибкостью? — а если совсем красиво, размещайте метаинформацию на быстром flash а данные на hdd (например та же jfs имеет соответствующие опции)
p.s. У меня только одно предложение по улучшению текущей технологии — замените механику перемещения головки на неподвижную серию микродатчиков, по одному на дорожку. Я думаю с современным техпроцессом это не составит никакого труда и выглядеть это будет как слоеный пирог из блинов — подвижных (с данными как сейчас) и неподвижных, или вращающихся в противоположную сторону (что аналогично ускорению вращения в два раза) — с сотнями или тысячами считывающих головок (например, размещенных по спирали).
про 3 — а разве серверные NAS-ы не являтся тем о чем вы пишете, но с большей гибкостью? — а если совсем красиво, размещайте метаинформацию на быстром flash а данные на hdd (например та же jfs имеет соответствующие опции)
p.s. У меня только одно предложение по улучшению текущей технологии — замените механику перемещения головки на неподвижную серию микродатчиков, по одному на дорожку. Я думаю с современным техпроцессом это не составит никакого труда и выглядеть это будет как слоеный пирог из блинов — подвижных (с данными как сейчас) и неподвижных, или вращающихся в противоположную сторону (что аналогично ускорению вращения в два раза) — с сотнями или тысячами считывающих головок (например, размещенных по спирали).
Головка довольно сложная (и дорогая в производстве), увеличение их кол-ва — это значительное удорожание. Не могу представить как вы заставите эту линейку парить над поверхностью. А закрепить жестко — это какая-то фантастическая точность должна быть (и цена).
Считывающая и записывающие головки как я понимаю уже давно производятся так же как и обычные полупроводниковые микросхемы — стреолитографией (может для записи будет посложнее), и основная сложность — механика и удержание расстояния.
Я предлагаю не полоску а сразу целый диск — кажется тут вообще не понадобится сложной системы удержания расстояния и можно использовать вакуум, так же диск позволит разместить головки по всей его поверхности.
По поводу точности — не нужна она, главное повторяемость, т.е. там где записали должны и читать, ведь поверхность диска однородна.
Я предлагаю не полоску а сразу целый диск — кажется тут вообще не понадобится сложной системы удержания расстояния и можно использовать вакуум, так же диск позволит разместить головки по всей его поверхности.
По поводу точности — не нужна она, главное повторяемость, т.е. там где записали должны и читать, ведь поверхность диска однородна.
1 — Несколько путаете рапределеный доступ к разным данным, и доступ к одному набору данных.
Для распределенного доступа можно наставить жестких дисков, разделить даные на горячие и холодые
но когда вам нужно модифицировать таблицу базы даных на 20 записей вы не заметите (данные считаются полностью модифицируются после их можно куском записать), но когда объем данных превысит объем кэша и оперативной памяти вот тогда и начнутся тормоза, тк освобождая кэш диск будет производить запись старых данных, а паралельно ему еще надо считать новую порцию. единственный способ не убить диск будет работать с большими кусками даных, а чем больше кусок для одной операции, тем больший объем данных мы рискуем потерять в случае сбоя.
3 — NAS- частный случай узкоспециализированного компьютера, заточенного для файловых операций, внедрение ФС в сам диск (причем это должно быть как дополнительная опция «магнитолка в машине, без магнитолки машина поедет, но как-то приятно когда есть»)
микросмещение и прощайте данные, вариант такой был, магнитный барабан с планкой, насколько помню выполнял роль оперативной памяти
Для распределенного доступа можно наставить жестких дисков, разделить даные на горячие и холодые
но когда вам нужно модифицировать таблицу базы даных на 20 записей вы не заметите (данные считаются полностью модифицируются после их можно куском записать), но когда объем данных превысит объем кэша и оперативной памяти вот тогда и начнутся тормоза, тк освобождая кэш диск будет производить запись старых данных, а паралельно ему еще надо считать новую порцию. единственный способ не убить диск будет работать с большими кусками даных, а чем больше кусок для одной операции, тем больший объем данных мы рискуем потерять в случае сбоя.
3 — NAS- частный случай узкоспециализированного компьютера, заточенного для файловых операций, внедрение ФС в сам диск (причем это должно быть как дополнительная опция «магнитолка в машине, без магнитолки машина поедет, но как-то приятно когда есть»)
микросмещение и прощайте данные, вариант такой был, магнитный барабан с планкой, насколько помню выполнял роль оперативной памяти
Жесткий диск в последнее время сдает позиции в борьбе с SSD на стороне которого быстродествие и отсутсвие панического страха к вибрациям, спасаясь только за счет дешевой стоимости размещения гигабайта данных и большего количества циклов перезаписи. Давайте подумаем, помогут ли несколько следующих идей дать фору для HDD.
Я так не думаю. В свете последних исследований — на гике где-то была статья — SSD опасны тем, что теряют информацию при отсутствии питания. Т.е. не получится записать данные, положить в шкафчик и забыть на какое-то неопределенное время. А с классическим жестким диском такой фокус проходит — у меня есть несколько винтов, которые хранят информацию. Какую? Резервные копии в осном конечно. Понравившиеся фильмы. Да образ kiwix той же википедии — при нынешних тенденция явно будет нелишним. Вероятность размагничивания поверхности гораздо ниже вероятности потери данных во flash.
если знать принцип хранения данных то вопросов почему так не возникнет, Ранние ПЗУ элементы стирались УФ излучением, процесс длительный, данные стирались все, но в случае записи хранились 25 лет вроде, потом уменьшили толщину диэлектрика, стирать можно стало электричеством, данные хранились уже 10 лет, сейчас для ускорения стирания/записи наверняка глубину затвора еще уменьшили чтобы можно было быстрее писать/стирать. Ток утечки увеличился. Сколько будут храниться данные без перезаписи?
Ну, такое применение, это не то, для чего существуют HDD и SSD. Для длительного архивного хранения больших массивов данных есть специальные решения, вроде ленточных накопителей. Это совершенно недомашний вариант, но дома это вообще мало кому надо. В крайнем случае, существуют оптические диски, которые при правильном хранении крайне живучи. В общем, вряд ли жесткие диски не сдохнут по той причине, что некоторые домашние пользователи не могут хранить SSD на полке десятилетиями.
Делегация файловой системы не катит. Дыры в файлах, copy on write, снапшоты, ctime/mtime/atime, диапазонные блокировки, posix-блокировки (обязательные и нет), fsync'и, etc. Всё это реализовать в HDD — получится сервер с «жёстким диском».
В принципе, object storage как диск уже продают, но за негуманные деньги.
Шпиндельные диски из 7200 живут только массой и ценой. Любые телодвижения в этой области резко повысят цену (из-за ухода из массовости). Так что молча гнать гигабайты вверх, цену вниз, и не париться. Никаких перспектив у шпинделей нет, кроме как NL-хранилища и миллиардов легаси из СХД (на которых ещё лет 20 кормиться будут).
В принципе, object storage как диск уже продают, но за негуманные деньги.
Шпиндельные диски из 7200 живут только массой и ценой. Любые телодвижения в этой области резко повысят цену (из-за ухода из массовости). Так что молча гнать гигабайты вверх, цену вниз, и не париться. Никаких перспектив у шпинделей нет, кроме как NL-хранилища и миллиардов легаси из СХД (на которых ещё лет 20 кормиться будут).
для домашнего использования может и не пойдет, а вот для энтерпарйз решения, где удвоение количества IOPS будет очень кстати
ну вот, я уже могу спать спокойнее, осталось про диск с двумя блоками узнать, было или нет, и можно придумывать следующую нелепую идею.
был такой зверь.
en.wikipedia.org/wiki/Conner_Peripherals
… Conner produced a limited number of dual-actuator drives (internally called «Chinook») for high-throughput applications. These drives used the SCSI interface and had two independently controlled (by the embedded microprocessor) servo and read/write systems, and two complete sets of read/write heads. The drive firmware enabled it to dynamically re-order commands and assign them to a specific read/write system for optimum execution time, and perform read-write-verify and read-exclusive or-write operations twice as fast as comparable single actuator systems.
en.wikipedia.org/wiki/Conner_Peripherals
… Conner produced a limited number of dual-actuator drives (internally called «Chinook») for high-throughput applications. These drives used the SCSI interface and had two independently controlled (by the embedded microprocessor) servo and read/write systems, and two complete sets of read/write heads. The drive firmware enabled it to dynamically re-order commands and assign them to a specific read/write system for optimum execution time, and perform read-write-verify and read-exclusive or-write operations twice as fast as comparable single actuator systems.
и вроде еще вот этот ftp.seagate.com/acrobat/install_guides/barracuda/8900a.pdf
Seagate точно классической конфигурации, на одной поверхности один блок головок работает только.
Про conner описывается чудесный прирост производительности, но нет пояснения за счет чего, толи это две головки на одной поверхности как в моей идее, или что то наподобие того девайса который изображен на видео в комментариях выше, где два блока головок работают со своими дисками, что позволяет распределить нагрузку, но если один привод головок сломается то мы потеряем половину емкости. Conner сдулся за счет более дешевых конкурентов с одним приводом.
Про conner описывается чудесный прирост производительности, но нет пояснения за счет чего, толи это две головки на одной поверхности как в моей идее, или что то наподобие того девайса который изображен на видео в комментариях выше, где два блока головок работают со своими дисками, что позволяет распределить нагрузку, но если один привод головок сломается то мы потеряем половину емкости. Conner сдулся за счет более дешевых конкурентов с одним приводом.
добавил ваш комментарий к статье, а то народ по прежнему комментирует что это никому не нужно
Как вы уже правильно заметили в самом начале статьи, единственные причины по которым жесткие диски еще существуют — это цена и объем.
Все ваши предложения увеличивают цену или уменьшают полезный объем. А значит напрямую приводят к тому, что получается проще и выгоднее просто купить SSD.
Место HDD в современном мире — neraline & archive storage. А там ни скорость доступа так не важна, ни надежность внутри одного диска. Ибо все равно надо резервирование целых дисков. Так что пусть будут больше по объему.
P.S. Что касается 3-го пункта, то вы описали классический NAS. Их есть. То, что он реализован в firmware или в софте коробки — это уже неинтересные пользователю детали.
Все ваши предложения увеличивают цену или уменьшают полезный объем. А значит напрямую приводят к тому, что получается проще и выгоднее просто купить SSD.
Место HDD в современном мире — neraline & archive storage. А там ни скорость доступа так не важна, ни надежность внутри одного диска. Ибо все равно надо резервирование целых дисков. Так что пусть будут больше по объему.
P.S. Что касается 3-го пункта, то вы описали классический NAS. Их есть. То, что он реализован в firmware или в софте коробки — это уже неинтересные пользователю детали.
Что касается последнего пункта, я где-то читал, что производители винчестеров уже экспериментируют с распознаванием файловых систем, чтобы оптимизировать работу диска, но это происходит исключительно внутри девайса. Для процессора и ОС в плане работы он ничем не отличается от более тупых собратьев.
Может быть работу кэша оптимизируют для определённого паттерна использования? Например, предполагать, где расположены индексы ФС (айноды, битмапы, не знаю), и давать им больше веса в кеше, чтобы они тяжелее выталкивались, всё-равно скоро понадобятся. Это как тюнинг движка БД, зная (предполагая) тип нагрузки и имея резервы мощности можно получить весомый прирост производительности, управляя интеллектуально.
Sign up to leave a comment.
Несколько нелепых идей для производителей жестких дисков