Жесткий диск состоит из одного или нескольких тонких дисков с ферромагнитной поверхностью закрепленных на шпинделе, раскручиваемых двигателем до скорости в несколько тысяч оборотов в минуту. Отдельной частью является блок головок который перемещается вдоль радиуса диска. Если раньше использовались системы которые перемещали блок головок по прямой (наподобие системы которая используется в CD/DVD), то сейчас как правило используется коромысло. На одном конце коромысла закреплены головки, с другой стороны располагается система перемещения. По началу за все перемещения отвечали сервоприводы, но после того как научились делать сильные магниты «много и дешево» начал использоваться механизм взаимодействия магнитного поля магнита и электромагнитных полей катушки провода на которую подается электрический ток.
В качестве хранилища жесткий диск дает три измерения:
- сilinder – представляет из себя некую дистанцию от центра диска, вдоль которой происходят операции чтения, записи, и перед тем как их начать, необходимо переместить блок головок на тот или иной цилиндр;
- head -каждая сторона диска на поверхности которой можно размещать данные, и над которой соответственно размещена головка, так-же есть понятие «дорожка» которое определяет данные размещенные на определенной поверхности на заданном цилиндре;
- segment – кусочек окружности дорожки размещенной на одной из рабочих поверхностей вдоль которого собственно и размещен кусочек данных.
Для того, чтобы считать сегмент данных, жесткий диск должен переместить блок головок к необходимому цилиндру, выбрать поток данных с нужной головки и дождаться пока диск не повернется нужным сегментом под блок головок и только после этого можно прочитать или записать данные.
Время доступа к данным варьируется от того на сколько вы счастливчик, и тут есть несколько ситуаций.
Случай 1: вы везунчик, и после поступления команды на чтение жесткий диск увидел, что блок головок расположен на нужном цилиндре, начинает считывать данные и первый считанный сегмент оказывается тем, что нужен. Для того чтобы посчитать насколько вам повезло, попробуем посчитать время сколько займет данная операция:
Определим переменные:
- t1-время передачи команды жесткому диску;
- t2-время обработки команды жестким диском;
- t3-позиционирование блока головок;
- t4-время перемещения сегмента к блоку головок;
- t5-время считывания одного сегмента;
- t6-время передачи данных от жесткого диска по интерфейсу
t3 и t4 для описанного случая стремятся к нулю и мы их проигнорируем, так-же как время передачи команды t1 (для 10-12 байт команды это будет 1/100 часть от данных) и время обработки команды t2 (зависит от сложности вычислений и быстродействия процессора, но будем считать что он достаточно быстр чтобы проигнорировать этот период).
Остаются t5 и t6, чтобы рассчитать эти значения возьмем характеристики интерфейсов и потоковое считывание с диска (скорость считывания некоторого количества сегментов подряд с одной дорожки). Для простоты расчетов, определим что сегмент объемом 1000 байт (в реальности он 512 или 4096 байт данных плюс некоторое количество служебных данных), а потоковое считывание как 50 Мб/с (есть больше, есть меньше).
t5 — 1000 байт * (1 / 50000000 байт/с) = 20 мкс на считывание/запись одного сегмента
t6 — зависит от скорости передачи данных, посчитаем его для разных интерфейсов:
IDE
- DMA33 – 33 Мб/с = 1000* (1/33 000 000) = 30 мкс (больше чем время потраченное на считывание)
- DMA66 – 66 Мб/с = 1000* (1/66 000 000) = 15 мкс
- DMA100 – 100 Мб/с = 1000* (1/100 000 000) = 10 мкс
SATA
- SATA I -1500 Гбит/с=150 Мб /с = 1000* (1/150 000 000) = 6.6 мкс
- SATA II/SAS -3000 Гбит/с=300 Мб /с = 1000* (1/300 000 000) = 3.3 мкс
- SATA III/SAS 2 -6000 Гбит/с=600 Мб /с = 1000* (1/600 000 000) = 1.6 мкс
Почему я поделил скорость SATA на 10 хотя в байте 8 бит? Дело в том что передача происходит в последовательном режиме и для того чтобы передать данные достоверно, используются либо сигналы синхронизации (стартовый и стоповый биты, привет COM-порт) либо данные перекодируются для того чтобы не получить на выходе насыщенный канал используются кодирование такое что не смотря на значение исходного потока байта (все 0 или 255), в результате получаем комбинацию с равным количеством нулей и единиц, так-же за счет перекодирования сигнала снижается частота сигнала (да, частота меньше а скорость больше).
Итого, получаем, что в случае везения, вы получите свои данные через 21.6 – 50 мкс, причем из расчетов данного случая вы понимаете зачем производители создают новые скоростные интерфейсы не смотря на то что скорость чтения с дисков значительно медленнее (чем быстрее интерфейс связи, тем быстрее ваши данные могут быть переданы с момента их готовности между отправителем и получателем).
Случай 2: вам повезло не так сильно, и нужно переместить блок головок на другой цилиндр, а после того как будет найден нужный цилиндр, необходимо подождать еще когда диск повернется на 180 градусов для доступа к нужному сегменту.
К сожалению о времени перемещения и позиционирования головки мне не известно, зато можно посчитать сколько времени нужно для перемещения сегмента по кругу, и примем время позиционирования равным половине времени оборота диска, а эта величина известна, и так, считаем время оборота диска (половина на позиционирование, половина на доворот диска для считывания).
Для того, чтобы посчитать нужно узнать сколько оборотов происходит за секунду, и далее узнать период разделив 1 на количество оборотов:
5400 об/мин – 1(5400/60)= 11мс
5900 об/мин – T=10 мс
7200 об/мин – T=8 мс
10000 об/мин – T=6 мс
15000 об/мин – T=4 мс
Какие-то знакомые значения, не находите? Точно! Среднее время доступа данных для диска примерно или равняется периоду оборота диска, почему среднее? Потому что есть:
Случай 3: вам не повезло, блок головок находится на первом цилиндре, а сегмент расположен на последнем, время перемещения блока головок заняло почти или столько же как и период вращения диска, после того как блок головок был позиционирован на нужном цилиндре, и началось считывание данных, оказалось что мы получили следующий после нужного сегмент, и для того чтобы его прочитать, нужно подождать когда диск совершит еще один оборот, при этом я промолчу про случай 4: когда данные с первого (и возможно и последующего) раза не были прочитаны (посчитать сколько времени это займет легко, миниум 2 * T об.).
Какой можно сделать вывод на данном этапе? «Эврика: нужно раскрутить шпиндель до 100500 оборотов!». Но не все так просто, если вы крутились на карусели, вы должны знать что если карусель крутится не слишком быстро, то на ней легко удержаться в любой части, если карусель раскручена слишком быстро, единственный способ удержаться это быть ближе к центру и крепко держаться. Что произойдет с дисками если их раскрутить сильно: сначала края диска начнут разбегаться в разные стороны за счет центробежных сил, и диск начнет сначала расплываться в разные стороны увеличиваясь, а так как скорость вращения не уменьшается, а размер диска увеличивается, с ним увеличиваются и центробежные силы, что приводит к разрушению молекулярных связей и получаем «бигбадабум», и несколько кусков от диска. Вот по причине воздействия центробежных сил высокооборотные диски делают меньшего диаметра, чтобы их не порвало.
Вот тут и появляется первая нелепая идея: почему нельзя сделать два блока головок расположенных друг напротив друга вместо одного (а если получится с двумя, то пробовать 3, 4 может даже и 5, 6). Что это нам дает:
1) с увеличением количества деталей, «уменьшается надежность» системы, но так как мы получаем дублирующую систему, мы «увеличиваем надежность».
2) блоки головок перемещаются синхронно (импульсы вызванные перемещением головок не действуют во время считывания/записи данных), и если сегмент только что проскочил, то второй блок головок получит шанс считать его через T об./2 (для этого нам в классическом случае нужно было бы раскрутить шпиндель в два раза быстрее).
3) блоки головок действуют по отдельным заданиям (влияние импульсов перемещения блока головок не существенно для операций чтения/записи), контроллер зная где находится тот или иной сегмент, может переместить самый выигрышный по позиции блок головок, для уменьшения времени теряемых на вращении шпинделя и количество операций ввода вывода увеличится в два раза.
4) Есть две ситуации, когда нам нужно обработать большое количество данных сразу:
-копирование/перемещение большого файла (привет Blu-ray);
-чтение-модификация-запись одного файла (привет базам данных).
В классическом варианте жесткого диска, при копировании, мы считываем блок данных в буфер, перемещаем блок головок в другую часть, записываем данные, возвращаемся за новой порцией данных, при небольшом объеме буфера, мы теряем огромное количество времени на перемещениях блока головок при большом объеме данных. В случае с модификацией одного файла, мы заполняем буфер, модифицируем его (это можно делать параллельно со считыванием, как только получены первые данные в нужной комплектации), и после модификации записываем. В модифицированной схеме, мы можем скопировать файл на максимальной скорости, одним блоком головок считывая данные, а вторым блоком записывая их на максимально-возможной скорости, которое будет зависеть в первую очередь от фрагментации файла, сейчас для жестких дисков такое возможно в случае применения двух дисков, с одного считывать, на другой записывать.
Вторым аспектом работы жесткого диска является его надежность, а в частности типовые неисправности, опустим неисправности логики программы, это нужно чинить в другом месте, озвучу только неисправности, которые зависят от конструктивных особенностей жесткого диска:
- заклинивание шпинделя во время старта (ну тут есть шанс прокрутить шпиндель внешним воздействием, запустить диск, считать данные и отправить на упокой);
- заклинивание шпинделя во время работы (тут последствия уже все зависит от вашего везения);
- в результате длительной работы без должного охлаждения, в случае отключения диска, есть вероятность того что опустившись на поверхность головки прикипят, и во время старта или шпиндель не сможет раскрутить диски (клин) либо головки получат новые оси свободы (данную ситуацию производители дисков начали обходить паркуя блок головок вне поверхности диска, и они ее не касаются в обычной ситуации);
- во время работы диска он получает импульс воздействия направленный перпендикулярно поверхности диска, что может привести к касанию головок с поверхностью, что в свою очередь может привести к разрушению поверхности, с выбиванием частиц, которые начнут летать внутри гермоблока периодически влетая в головки или под них, плодясь и умножая себе подобных они рано или поздно приведут к разрушению и невозможности считать данные;
- другой случай когда во время работы, диск получает внешнее воздействие направленное параллельно рабочей поверхности, во время считывания диск не сможет прочитать данные и сделает второй заход, а во время записи, такое воздействие может привести к тому что записываемый сегмент данных будет записан не в цилиндре а поперек нескольких.
Всем известно что самую большую ценность представляет из себя не стоимость жесткого диска (привет $-у), а те гигабайты бережно собранного «по… лезной информации». Для того, чтобы сохранить данные, используются RAID системы разного уровня, для которых необходимо использовать несколько жестких дисков. Вот на этом появляется вторая нелепая идея: использование технологий RAID в рамках одного диска.
В случае полного отказа диска конечно не спасет но в случае потери данных с 1-2 сегментов, вполне поможет исправить ситуацию.
Подход первый, который легко реализуется программным методом, заключается в том чтобы всю поверхность, или только критические или важные данные (0 сегмент, таблица разделов, файлы конфигурации системы) размещать по технологии RAID 5: А+Б=Сумма, получив две части из трех мы легко восстановим третью, зеркало или дублирование довольно широко используется например в NTFS дублируется несколько записей Master File Table, но это мало чем спасает в случае серьёзного сбоя, кроме того «зеркало» теряет половину объема в дубле, тогда как в случае сбора статистики по нечитаемым сегментам, можно реализовать возможность размещения данных по принципу «А+Б+В+Г+Д+Е+Ж+З=И» мы потеряем 1/9 часть объема, но увеличим вероятность восстановления данных в случае потери 1 сегмента данных.
Подход второй, связанный с модификацией логики работы контроллера заключается в том, чтобы используя принцип с контрольной суммой, размещать данные не вдоль одной дорожки, а на разных поверхностях дисков, такая реализация позволит спасти ситуацию когда одна из рабочих головок перестала совсем отвечать, мы всегда считав значения с других поверхностей получим исходные данные, ну а сохранив данные мы можем торжественно упокоить страдальца.
Собственно
спасибо: owniumo
Уже есть: Жесткий диск Kinetic для масштабируемой объектной системы хранения данных
Чем это поможет: центральный процессор будет передавать только дескриптор файла, и какой кусок ему нужен, перестав отвлекаться на прерывания связанные с построением цепочки FAT например, а контроллер сам просчитает, где указанные куски хранятся, и выдаст контроллеру только нужный кусок файла.
Реализовать это можно:
- разработкой и заменой заводской прошивки (возможно и на текущем железе, но затратно в плане последующих модификаций, и количества вариантов дисков, привет разработчикам мобильных приложений);
- разработка файловой системы которую будут поддерживать прошивки производителей дисков;
- разработка и внедрение в прошивку языка программирования с помощью которого можно описать работу с файловой системой
Вот собственно три нелепых идеи, которые сложно проверить самому, а спокойно спать они не дают.
P.S. случайное использование зарегистрированных товарных знаков или патентов является случайным. Все оригинальные идеи доступны для использования по лицензионному соглашению «муравейник».
Комментарии (39)
VBKesha
24.08.2015 13:57Всё это сделать можно но:
1. Значительно увеличит стоимость диска, повысит шанс что головки упадут на диск и запилят блины на 50%
2. Данные и так уже давно пишутся на обе поверхности диска. В итоге это уменьшит доступный объём диска, но стоимость оставит туже, однако никак не защити от проблем шпинделя, контроллера и выхода из строя целиком всего блока головок.
3. Процессор куда быстрей построит цепочки FAT чем диск, это во первых, во вторых файловых систем много не спроста, и ограничивать себя одной смысла нету.
kasperos
24.08.2015 16:241 вероятность рассчитывается не так просто,
2. речь идет не о том что «оказывается писать можно на двух сторонах», об этом известно еще со времен флопповодов, речь идет о распределении даных по принципу RAID системы, но не между физическими устройствами, а на разных поверхностях, на одной из них пишется «контрольная сумма» остальных даных с других поверхностей.
3. FAT32 позволяет организовать цепочку почти в 16 Гб, если есть место в оперативной памяти хранить 16 Гб, то да, согласен процессор быстрее просчитает, в противном случае контроллер диска узнает минимум на 5 мкс быстрее где следующий кластер.
файловых систем много: наследие, новые вызовы по объемам, разное поведение на разных ситуациях и на разных носителях. ну и «патенты».VBKesha
24.08.2015 16:402. Вы потеряете объём одной стороны одного диска, допустим их было 2 блина по 1Tb каждый. Итого у вас диск превратится из диска на 2Tb в диск на 1.5Tb и теперь он способен пережить сметь одной головки. Но стоить он продолжил как 2Tb а надежность ну про неё трудно сказать насколько она выросла. Плюс диск теперь вынужден делать больше операций записи что скажется на их скорости.
3. А в реальности какие обычно цепочки на переносных дисках с FAT32? И сколько памяти нужно для их хранения?kasperos
24.08.2015 18:152. выросла надежность хранения данных, за счет сокращения объема хранения данных, тут уже нужна статистика как часто встречается ситуация повреждения 1 сектора в последовательности из 4-5 (если хранить данные на одной дорожке). что касается записи:
-ситуация когда можно писать одновременно на все дорожки маловероятна, но реальна.
-рассмотрим более вероятную ситуацию, когда запись идет последовательно, и между процедур записи необходимо заложить время необходимое для доводки следующей головки точно по дорожке. тут уже нужно резюме людей кто занимается разработкой и изготовлением HDD. Samsung, Hitachi, WD, Seagate, есть тут кто в правило 6 рукопожатий уложиться до инженеров?
3. для 2 гб файла (предел фат32) и 64 кб в вырожденном случае составит:
2Гб/64кб=32768 транзакций передачи данных по 64 кб около 3 секунд
при 4 кб кластере получиться 524288 транзакций примерно те-же 3 секунды
в реальности конечно вырожденные случаи редки, но сам факт того если при обработке данных мы можем сэкономить 3 секунды, стоит задуматься.
radiolok
24.08.2015 14:15+1Свою первую нелепую идею в «крупном масштабе» можете лицезреть в обзоре от Дейва.
На весь «четвертьлямобаксовый» хард два независимых блока головок по 2 головки на сторону.
Как итог — это уже придумали до вас.
Вторая нелепая идея разбивается о выход из строя диска целиком. Сдох контроллер — как восстановить данные? Посыпался диск — посыпался весь — кто будет восстанавливать данные? Я просто выкину нерабочий диск и воткну рабочий и запущу процедуру восстановления массива с других отдельных хардов. В отличие от харда из видео в современных хардах нельзя просто так взять иборомирзаменить посыпавшуюся пластину или головку. И делать это никто, кроме МАК не будет. Последним просто по роду деятельности приходится этим заниматься.
Третья нелепая идея утыкается на ворох файловых систем (комикс xkcd о стандартах). В итоге для одних ФС надо будет покупать одни харды, для других — другие. Универсальность? нет, не слышал. Мне сложно представить контроллер для харда, поддерживающий все вышедшие и невышедшие файловые системы. Только если этот контроллер не мини-компьютер. Менять прошивку? А если поддержка закончилась? Менять всю СХД целиком? Нет уж. Делегирование функций штука полезная, но только тогда, когда это приносит пользу.kasperos
24.08.2015 14:35классическая схема, с тем изменением что можно посылать два запроса в разные части диска, но нельзя сделать два запроса к одному
смотрел видео в надежде что начну спать спокойно, но пока нет.
добавил картинку для пояснения, что я имел в виду.
одним из вариантов реализации было разработка языка с помощью которого можно описать файловую систему, пример тому SQL, вы можете использовать разные сервера баз данных, но все сервера поддерживающие SQL вернут вам идентичный (в теории) ответ на одном наборе даных
owniumo
25.08.2015 07:02Уже есть: Жесткий диск Kinetic для масштабируемой объектной системы хранения данных
Первый в мире жесткий диск с интерфейсом Ethernet и поддержкой API с открытым исходным кодом, разработанный специально для сверхмасштабируемых и горизонтально масштабируемых сред. Seagate Kinetic HDD упрощает процесс создания программных и аппаратных архитектур хранения данных, снижая совокупную стоимость владения (ТСО) и позволяя оперативно реагировать на растущие потребности облачной инфраструктуры систем хранения данных.
API это файловая система и даже больше.
kasperos
24.08.2015 14:17+1да простят меня дизайнеры нарисовавшие исходное изображение, но что попалось первым.
AlanDrakes
24.08.2015 14:47Про сектора уже вспомнили, так что прицеплюсь к другому.
А собственно, КАК жёсткий диск (контроллер) должен знать, где находится какой сектор и какое положение шпинделя (угловое) в текущий момент? Ответ: А никак. Если таблица секторов ещё помещается в память контроллера (все помнят, что с переходом на LBA, одинаковое количество секторов на цинидр перестало быть одинаковым? (На самом деле — даже несколько раньше)).
Так вот. Контроллер жёсткого диска приблизительно знает, где искать нужный сектор (плюс, опять же, информация о переразмещённых секторах) и располагает головки над определённым цинидром. Да, процедура не столь быстрая (хотя и вполне шустро происходит), но механика есть механика, и иногда головка пролетает дальше, или же не долетает до нужного. Как узнать? По сервометкам на диске. Из них же получаются и номера секторов под головкой. А уж потом происходит коррекция, или ожидание сектора.
Так что, изготовить несколько блоков головок — технически возможно. Но бесполезно. Из этого мало чего можно выиграть сейчас. Особенно, для жёстких дисков с приличным размером КЭШ памяти.
speakingfish
24.08.2015 15:30Для целей считывания/записи одновременно двух секторов одного цилиндра — смысла нет. Но для разных цилиндров таки есть, поскольку экономится время позиционирования. Ну и скорость передачи данных будет больше в два раза, хоть и ценой двукратного увеличения стоимости, но зато в одном корпусе.
kasperos
24.08.2015 15:43мы сэкономим на блинах, и шпинделе
speakingfish
24.08.2015 16:02Ну допустим не в два а в полтора раза дороже. За увеличение скорости до двух раз. Это было бы уже неплохо.
kasperos
24.08.2015 15:55Одинаковое количество секторов на дорожке никак не связано с внедрением LBA, LBA (для IDE) разработано тогда, когда объем диска пришел к пределу классической адресации CHS (там уже пошли в разброд кто в лес кто по дрова) и по началу запросы CHS транслировались в свою адресацию.
Тот же SCSI изначально был ориентирован на LBA.
kasperos
24.08.2015 15:39откуда инжекторный двигатель сгорания знает в какой момент нужно на определенную свечу подать электрический импульс?
контроллер основываясь на информации, какой период занял предыдущий оборот двигателя, он рассчитывает в какой момент ему нужно подать зажигание.
Вычислить где должен (по идее) находиться сектор вопрос чистой математики.
Удвоение IOPS для вас не показатель? Что касается приличного объема КЭШ памяти, все хорошо пока объем данных вписывается в рамки кэша и объема основной оперативной памяти. Скопируйте 2 терабайта при чем задом наперед
PS промахнулся к AlanDrakes
rPman
24.08.2015 20:59+1про 1 — круто но дорого, потому как увеличение сложности в два раза увеличить скорость в лучшем случае тоже в два раза (а в среднем небось квадратный корень из количества головок). Полагаю конечному потребителю эффективней купить несколько дисков с одной головкой (и так же увеличить себе скорость случайного доступа) чем увеличивать стоимость железок без увеличения их суммарной емкости!
про 3 — а разве серверные NAS-ы не являтся тем о чем вы пишете, но с большей гибкостью? — а если совсем красиво, размещайте метаинформацию на быстром flash а данные на hdd (например та же jfs имеет соответствующие опции)
p.s. У меня только одно предложение по улучшению текущей технологии — замените механику перемещения головки на неподвижную серию микродатчиков, по одному на дорожку. Я думаю с современным техпроцессом это не составит никакого труда и выглядеть это будет как слоеный пирог из блинов — подвижных (с данными как сейчас) и неподвижных, или вращающихся в противоположную сторону (что аналогично ускорению вращения в два раза) — с сотнями или тысячами считывающих головок (например, размещенных по спирали).
Stalker_RED
24.08.2015 23:45Головка довольно сложная (и дорогая в производстве), увеличение их кол-ва — это значительное удорожание. Не могу представить как вы заставите эту линейку парить над поверхностью. А закрепить жестко — это какая-то фантастическая точность должна быть (и цена).
rPman
25.08.2015 00:10Считывающая и записывающие головки как я понимаю уже давно производятся так же как и обычные полупроводниковые микросхемы — стреолитографией (может для записи будет посложнее), и основная сложность — механика и удержание расстояния.
Я предлагаю не полоску а сразу целый диск — кажется тут вообще не понадобится сложной системы удержания расстояния и можно использовать вакуум, так же диск позволит разместить головки по всей его поверхности.
По поводу точности — не нужна она, главное повторяемость, т.е. там где записали должны и читать, ведь поверхность диска однородна.
kasperos
25.08.2015 07:391 — Несколько путаете рапределеный доступ к разным данным, и доступ к одному набору данных.
Для распределенного доступа можно наставить жестких дисков, разделить даные на горячие и холодые
но когда вам нужно модифицировать таблицу базы даных на 20 записей вы не заметите (данные считаются полностью модифицируются после их можно куском записать), но когда объем данных превысит объем кэша и оперативной памяти вот тогда и начнутся тормоза, тк освобождая кэш диск будет производить запись старых данных, а паралельно ему еще надо считать новую порцию. единственный способ не убить диск будет работать с большими кусками даных, а чем больше кусок для одной операции, тем больший объем данных мы рискуем потерять в случае сбоя.
3 — NAS- частный случай узкоспециализированного компьютера, заточенного для файловых операций, внедрение ФС в сам диск (причем это должно быть как дополнительная опция «магнитолка в машине, без магнитолки машина поедет, но как-то приятно когда есть»)
микросмещение и прощайте данные, вариант такой был, магнитный барабан с планкой, насколько помню выполнял роль оперативной памяти
AlexanderS
24.08.2015 22:17Жесткий диск в последнее время сдает позиции в борьбе с SSD на стороне которого быстродествие и отсутсвие панического страха к вибрациям, спасаясь только за счет дешевой стоимости размещения гигабайта данных и большего количества циклов перезаписи. Давайте подумаем, помогут ли несколько следующих идей дать фору для HDD.
Я так не думаю. В свете последних исследований — на гике где-то была статья — SSD опасны тем, что теряют информацию при отсутствии питания. Т.е. не получится записать данные, положить в шкафчик и забыть на какое-то неопределенное время. А с классическим жестким диском такой фокус проходит — у меня есть несколько винтов, которые хранят информацию. Какую? Резервные копии в осном конечно. Понравившиеся фильмы. Да образ kiwix той же википедии — при нынешних тенденция явно будет нелишним. Вероятность размагничивания поверхности гораздо ниже вероятности потери данных во flash.kasperos
25.08.2015 07:49если знать принцип хранения данных то вопросов почему так не возникнет, Ранние ПЗУ элементы стирались УФ излучением, процесс длительный, данные стирались все, но в случае записи хранились 25 лет вроде, потом уменьшили толщину диэлектрика, стирать можно стало электричеством, данные хранились уже 10 лет, сейчас для ускорения стирания/записи наверняка глубину затвора еще уменьшили чтобы можно было быстрее писать/стирать. Ток утечки увеличился. Сколько будут храниться данные без перезаписи?
Iv38
26.08.2015 15:00Ну, такое применение, это не то, для чего существуют HDD и SSD. Для длительного архивного хранения больших массивов данных есть специальные решения, вроде ленточных накопителей. Это совершенно недомашний вариант, но дома это вообще мало кому надо. В крайнем случае, существуют оптические диски, которые при правильном хранении крайне живучи. В общем, вряд ли жесткие диски не сдохнут по той причине, что некоторые домашние пользователи не могут хранить SSD на полке десятилетиями.
amarao
24.08.2015 23:51Делегация файловой системы не катит. Дыры в файлах, copy on write, снапшоты, ctime/mtime/atime, диапазонные блокировки, posix-блокировки (обязательные и нет), fsync'и, etc. Всё это реализовать в HDD — получится сервер с «жёстким диском».
В принципе, object storage как диск уже продают, но за негуманные деньги.
Шпиндельные диски из 7200 живут только массой и ценой. Любые телодвижения в этой области резко повысят цену (из-за ухода из массовости). Так что молча гнать гигабайты вверх, цену вниз, и не париться. Никаких перспектив у шпинделей нет, кроме как NL-хранилища и миллиардов легаси из СХД (на которых ещё лет 20 кормиться будут).kasperos
25.08.2015 06:52для домашнего использования может и не пойдет, а вот для энтерпарйз решения, где удвоение количества IOPS будет очень кстати
amarao
25.08.2015 14:33Вы не удвоите количество IOPS'ов без writeback'а. Весь энтерпрайз, либо доволен тем, что есть, либо переходит на SSD. Кроме того, энтерпрайзу точно не хочется ничего менять в основах, а вы предлагаете именно это.
owniumo
25.08.2015 06:57kasperos
25.08.2015 07:55ну вот, я уже могу спать спокойнее, осталось про диск с двумя блоками узнать, было или нет, и можно придумывать следующую нелепую идею.
azarij
28.08.2015 15:09был такой зверь.
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.azarij
28.08.2015 15:15и вроде еще вот этот ftp.seagate.com/acrobat/install_guides/barracuda/8900a.pdf
kasperos
28.08.2015 15:55Seagate точно классической конфигурации, на одной поверхности один блок головок работает только.
Про conner описывается чудесный прирост производительности, но нет пояснения за счет чего, толи это две головки на одной поверхности как в моей идее, или что то наподобие того девайса который изображен на видео в комментариях выше, где два блока головок работают со своими дисками, что позволяет распределить нагрузку, но если один привод головок сломается то мы потеряем половину емкости. Conner сдулся за счет более дешевых конкурентов с одним приводом.
kasperos
26.08.2015 08:26добавил ваш комментарий к статье, а то народ по прежнему комментирует что это никому не нужно
ctapnep
25.08.2015 17:35Как вы уже правильно заметили в самом начале статьи, единственные причины по которым жесткие диски еще существуют — это цена и объем.
Все ваши предложения увеличивают цену или уменьшают полезный объем. А значит напрямую приводят к тому, что получается проще и выгоднее просто купить SSD.
Место HDD в современном мире — neraline & archive storage. А там ни скорость доступа так не важна, ни надежность внутри одного диска. Ибо все равно надо резервирование целых дисков. Так что пусть будут больше по объему.
P.S. Что касается 3-го пункта, то вы описали классический NAS. Их есть. То, что он реализован в firmware или в софте коробки — это уже неинтересные пользователю детали.kasperos
26.08.2015 06:23за 3 пункт все успокоились, сеагейт уже анонсировал привод с LAN интерфейсом, и своим API, судя по публикациям около или больше года назад.
Iv38
26.08.2015 15:07Что касается последнего пункта, я где-то читал, что производители винчестеров уже экспериментируют с распознаванием файловых систем, чтобы оптимизировать работу диска, но это происходит исключительно внутри девайса. Для процессора и ОС в плане работы он ничем не отличается от более тупых собратьев.
owniumo
26.08.2015 18:53Может быть работу кэша оптимизируют для определённого паттерна использования? Например, предполагать, где расположены индексы ФС (айноды, битмапы, не знаю), и давать им больше веса в кеше, чтобы они тяжелее выталкивались, всё-равно скоро понадобятся. Это как тюнинг движка БД, зная (предполагая) тип нагрузки и имея резервы мощности можно получить весомый прирост производительности, управляя интеллектуально.
Halt
1. ваши «сегменты» всю жизнь назывались секторами
2. ранние SCSI диски исторически имели независимые приводы головок
Неужели вы думаете, что разработчики жестких дисков такие наивные, что не отрабатывали подобные варианты? С увеличением числа движущихся частей растет количество отказов и стоимость изготовления.
Вместо изобретения велосипедов, я бы посоветовал почитать историю развития этого чуда техники и соответствующих решений.
kasperos
1. согласен
2. не согласен, ранние SCSI диски были на сервоприводах, весьма сомневаюсь что там на одной поверхности работали одновременно две рабочих головки в силу сложности точного позиционирования. В случае сбоя позиционирования: необходимо либо выставлять на 0 дорожку, либо полностью переформатировать диск, с потерей всех данных.
Современнай конструкция позволяет по силе считываемого сигнала выставить головку не по шагу сервопривода, а по силе считываемого сигнала.
идея в том, чтобы на одной поверхности работали одновременно две и более рабочих головки, на нескольких коромыслах в разных частях диска.
в силу инертности мышления, могли просто и не попробовать,
есть байка про то как на самолетах появилось два «магнето» что сильно увеличило надежность самолетов (а ведь это увеличение количества частей).
kasperos
добрался до дома, раскопал свою книжку: Джон Гудмэн «Секреты жесткого диска» изд. Киев 1994 года
угадайте что с тех пор кардинально изменилось в жестких дисках?
Halt
Который из сотен патентов назвать-то? Тут и перпендикулярная запись и запись с подогревом и туева хуча изменений в системах кодирования и восстановления ошибок. Не говоря про периферийные интерфейсы и геометрию.
kasperos
Раньше в машинах автомагнитолы не было, а после того как в машину внедрили автомагнитолу, это стало принципиально другое устройство.
Я спрашиваю про принципиальную разницу, методы кодирования вообще от связистов могло прилететь, с магнитооптикой я лично в 2000-х познакомился, жутко дорогой привод и носитель, диск есть а считать не на чем, вики говорит что в 80-х. уже появилась технология.
Пока я не вижу что кто-то пробовал такое сделать, сюда опубликовал с надеждой что кто-то где-то читал, слышал, а может и сам делал.
Чуть ниже видео прицепили, сначала подумал что чувак из двух старых дисков реализовал то что я думал, однако он разобрал старый SCSI диск который тупо позволял сделать два разных запроса к двум разным областям (почти как два жестких диска но с одним шпинделем и одним интерфейсом). Моя же идея позволит удвоить IOPS на одном наборе данных.