если знать принцип хранения данных то вопросов почему так не возникнет, Ранние ПЗУ элементы стирались УФ излучением, процесс длительный, данные стирались все, но в случае записи хранились 25 лет вроде, потом уменьшили толщину диэлектрика, стирать можно стало электричеством, данные хранились уже 10 лет, сейчас для ускорения стирания/записи наверняка глубину затвора еще уменьшили чтобы можно было быстрее писать/стирать. Ток утечки увеличился. Сколько будут храниться данные без перезаписи?
1 — Несколько путаете рапределеный доступ к разным данным, и доступ к одному набору данных.
Для распределенного доступа можно наставить жестких дисков, разделить даные на горячие и холодые
но когда вам нужно модифицировать таблицу базы даных на 20 записей вы не заметите (данные считаются полностью модифицируются после их можно куском записать), но когда объем данных превысит объем кэша и оперативной памяти вот тогда и начнутся тормоза, тк освобождая кэш диск будет производить запись старых данных, а паралельно ему еще надо считать новую порцию. единственный способ не убить диск будет работать с большими кусками даных, а чем больше кусок для одной операции, тем больший объем данных мы рискуем потерять в случае сбоя.
3 — NAS- частный случай узкоспециализированного компьютера, заточенного для файловых операций, внедрение ФС в сам диск (причем это должно быть как дополнительная опция «магнитолка в машине, без магнитолки машина поедет, но как-то приятно когда есть»)
микросмещение и прощайте данные, вариант такой был, магнитный барабан с планкой, насколько помню выполнял роль оперативной памяти
Раньше в машинах автомагнитолы не было, а после того как в машину внедрили автомагнитолу, это стало принципиально другое устройство.
Я спрашиваю про принципиальную разницу, методы кодирования вообще от связистов могло прилететь, с магнитооптикой я лично в 2000-х познакомился, жутко дорогой привод и носитель, диск есть а считать не на чем, вики говорит что в 80-х. уже появилась технология.
Пока я не вижу что кто-то пробовал такое сделать, сюда опубликовал с надеждой что кто-то где-то читал, слышал, а может и сам делал.
Чуть ниже видео прицепили, сначала подумал что чувак из двух старых дисков реализовал то что я думал, однако он разобрал старый SCSI диск который тупо позволял сделать два разных запроса к двум разным областям (почти как два жестких диска но с одним шпинделем и одним интерфейсом). Моя же идея позволит удвоить IOPS на одном наборе данных.
добрался до дома, раскопал свою книжку: Джон Гудмэн «Секреты жесткого диска» изд. Киев 1994 года
угадайте что с тех пор кардинально изменилось в жестких дисках?
2. выросла надежность хранения данных, за счет сокращения объема хранения данных, тут уже нужна статистика как часто встречается ситуация повреждения 1 сектора в последовательности из 4-5 (если хранить данные на одной дорожке). что касается записи:
-ситуация когда можно писать одновременно на все дорожки маловероятна, но реальна.
-рассмотрим более вероятную ситуацию, когда запись идет последовательно, и между процедур записи необходимо заложить время необходимое для доводки следующей головки точно по дорожке. тут уже нужно резюме людей кто занимается разработкой и изготовлением HDD. Samsung, Hitachi, WD, Seagate, есть тут кто в правило 6 рукопожатий уложиться до инженеров?
3. для 2 гб файла (предел фат32) и 64 кб в вырожденном случае составит:
2Гб/64кб=32768 транзакций передачи данных по 64 кб около 3 секунд
при 4 кб кластере получиться 524288 транзакций примерно те-же 3 секунды
в реальности конечно вырожденные случаи редки, но сам факт того если при обработке данных мы можем сэкономить 3 секунды, стоит задуматься.
1 вероятность рассчитывается не так просто,
2. речь идет не о том что «оказывается писать можно на двух сторонах», об этом известно еще со времен флопповодов, речь идет о распределении даных по принципу RAID системы, но не между физическими устройствами, а на разных поверхностях, на одной из них пишется «контрольная сумма» остальных даных с других поверхностей.
3. FAT32 позволяет организовать цепочку почти в 16 Гб, если есть место в оперативной памяти хранить 16 Гб, то да, согласен процессор быстрее просчитает, в противном случае контроллер диска узнает минимум на 5 мкс быстрее где следующий кластер.
файловых систем много: наследие, новые вызовы по объемам, разное поведение на разных ситуациях и на разных носителях. ну и «патенты».
Одинаковое количество секторов на дорожке никак не связано с внедрением LBA, LBA (для IDE) разработано тогда, когда объем диска пришел к пределу классической адресации CHS (там уже пошли в разброд кто в лес кто по дрова) и по началу запросы CHS транслировались в свою адресацию.
Тот же SCSI изначально был ориентирован на LBA.
откуда инжекторный двигатель сгорания знает в какой момент нужно на определенную свечу подать электрический импульс?
контроллер основываясь на информации, какой период занял предыдущий оборот двигателя, он рассчитывает в какой момент ему нужно подать зажигание.
Вычислить где должен (по идее) находиться сектор вопрос чистой математики.
Удвоение IOPS для вас не показатель? Что касается приличного объема КЭШ памяти, все хорошо пока объем данных вписывается в рамки кэша и объема основной оперативной памяти. Скопируйте 2 терабайта при чем задом наперед
PS промахнулся к AlanDrakes
классическая схема, с тем изменением что можно посылать два запроса в разные части диска, но нельзя сделать два запроса к одному
смотрел видео в надежде что начну спать спокойно, но пока нет.
добавил картинку для пояснения, что я имел в виду.
одним из вариантов реализации было разработка языка с помощью которого можно описать файловую систему, пример тому SQL, вы можете использовать разные сервера баз данных, но все сервера поддерживающие SQL вернут вам идентичный (в теории) ответ на одном наборе даных
1. согласен
2. не согласен, ранние SCSI диски были на сервоприводах, весьма сомневаюсь что там на одной поверхности работали одновременно две рабочих головки в силу сложности точного позиционирования. В случае сбоя позиционирования: необходимо либо выставлять на 0 дорожку, либо полностью переформатировать диск, с потерей всех данных.
Современнай конструкция позволяет по силе считываемого сигнала выставить головку не по шагу сервопривода, а по силе считываемого сигнала.
идея в том, чтобы на одной поверхности работали одновременно две и более рабочих головки, на нескольких коромыслах в разных частях диска.
в силу инертности мышления, могли просто и не попробовать,
есть байка про то как на самолетах появилось два «магнето» что сильно увеличило надежность самолетов (а ведь это увеличение количества частей).
а уж с блинчиками можно будет самим разобраться
Для распределенного доступа можно наставить жестких дисков, разделить даные на горячие и холодые
но когда вам нужно модифицировать таблицу базы даных на 20 записей вы не заметите (данные считаются полностью модифицируются после их можно куском записать), но когда объем данных превысит объем кэша и оперативной памяти вот тогда и начнутся тормоза, тк освобождая кэш диск будет производить запись старых данных, а паралельно ему еще надо считать новую порцию. единственный способ не убить диск будет работать с большими кусками даных, а чем больше кусок для одной операции, тем больший объем данных мы рискуем потерять в случае сбоя.
3 — NAS- частный случай узкоспециализированного компьютера, заточенного для файловых операций, внедрение ФС в сам диск (причем это должно быть как дополнительная опция «магнитолка в машине, без магнитолки машина поедет, но как-то приятно когда есть»)
микросмещение и прощайте данные, вариант такой был, магнитный барабан с планкой, насколько помню выполнял роль оперативной памяти
Я спрашиваю про принципиальную разницу, методы кодирования вообще от связистов могло прилететь, с магнитооптикой я лично в 2000-х познакомился, жутко дорогой привод и носитель, диск есть а считать не на чем, вики говорит что в 80-х. уже появилась технология.
Пока я не вижу что кто-то пробовал такое сделать, сюда опубликовал с надеждой что кто-то где-то читал, слышал, а может и сам делал.
Чуть ниже видео прицепили, сначала подумал что чувак из двух старых дисков реализовал то что я думал, однако он разобрал старый SCSI диск который тупо позволял сделать два разных запроса к двум разным областям (почти как два жестких диска но с одним шпинделем и одним интерфейсом). Моя же идея позволит удвоить IOPS на одном наборе данных.
угадайте что с тех пор кардинально изменилось в жестких дисках?
-ситуация когда можно писать одновременно на все дорожки маловероятна, но реальна.
-рассмотрим более вероятную ситуацию, когда запись идет последовательно, и между процедур записи необходимо заложить время необходимое для доводки следующей головки точно по дорожке. тут уже нужно резюме людей кто занимается разработкой и изготовлением HDD. Samsung, Hitachi, WD, Seagate, есть тут кто в правило 6 рукопожатий уложиться до инженеров?
3. для 2 гб файла (предел фат32) и 64 кб в вырожденном случае составит:
2Гб/64кб=32768 транзакций передачи данных по 64 кб около 3 секунд
при 4 кб кластере получиться 524288 транзакций примерно те-же 3 секунды
в реальности конечно вырожденные случаи редки, но сам факт того если при обработке данных мы можем сэкономить 3 секунды, стоит задуматься.
2. речь идет не о том что «оказывается писать можно на двух сторонах», об этом известно еще со времен флопповодов, речь идет о распределении даных по принципу RAID системы, но не между физическими устройствами, а на разных поверхностях, на одной из них пишется «контрольная сумма» остальных даных с других поверхностей.
3. FAT32 позволяет организовать цепочку почти в 16 Гб, если есть место в оперативной памяти хранить 16 Гб, то да, согласен процессор быстрее просчитает, в противном случае контроллер диска узнает минимум на 5 мкс быстрее где следующий кластер.
файловых систем много: наследие, новые вызовы по объемам, разное поведение на разных ситуациях и на разных носителях. ну и «патенты».
Тот же SCSI изначально был ориентирован на LBA.
контроллер основываясь на информации, какой период занял предыдущий оборот двигателя, он рассчитывает в какой момент ему нужно подать зажигание.
Вычислить где должен (по идее) находиться сектор вопрос чистой математики.
Удвоение IOPS для вас не показатель? Что касается приличного объема КЭШ памяти, все хорошо пока объем данных вписывается в рамки кэша и объема основной оперативной памяти. Скопируйте 2 терабайта при чем задом наперед
PS промахнулся к AlanDrakes
смотрел видео в надежде что начну спать спокойно, но пока нет.
добавил картинку для пояснения, что я имел в виду.
одним из вариантов реализации было разработка языка с помощью которого можно описать файловую систему, пример тому SQL, вы можете использовать разные сервера баз данных, но все сервера поддерживающие SQL вернут вам идентичный (в теории) ответ на одном наборе даных
2. не согласен, ранние SCSI диски были на сервоприводах, весьма сомневаюсь что там на одной поверхности работали одновременно две рабочих головки в силу сложности точного позиционирования. В случае сбоя позиционирования: необходимо либо выставлять на 0 дорожку, либо полностью переформатировать диск, с потерей всех данных.
Современнай конструкция позволяет по силе считываемого сигнала выставить головку не по шагу сервопривода, а по силе считываемого сигнала.
идея в том, чтобы на одной поверхности работали одновременно две и более рабочих головки, на нескольких коромыслах в разных частях диска.
в силу инертности мышления, могли просто и не попробовать,
есть байка про то как на самолетах появилось два «магнето» что сильно увеличило надежность самолетов (а ведь это увеличение количества частей).