Для выбора внешнего жесткого диска используйте каталог Onliner.by: catalog.onliner.by
Каталог боксов для жестких дисков
спасайте люди...
недалече как позавчера сдох мой многострадальный ИБМы...
терь надо в короткие сроки найти ему замену...
Для выбора внешнего жесткого диска используйте каталог Onliner.by: catalog.onliner.by
Каталог боксов для жестких дисков
спасайте люди...
недалече как позавчера сдох мой многострадальный ИБМы...
терь надо в короткие сроки найти ему замену...
Compiller, почти все современные винты AF. Теоретически при производстве ничто не мешает их делать на 512 байт, сектор. Но больше влезет данных, если делать сектор 4кб (меньше накладных расходов)
И меньше надёжность. Большие блоки - больше информации при повреждении этих блоков пропадает бесследно. Ну это так - следствие. Плюс за счёт пересчёта этих блоков из одного размера в другой на лету - больше вероятность возникновения ошибки.
Большие блоки - больше информации при повреждении этих блоков пропадает бесследно.
вопрос в емкости ЕСС, реализации по применимости ЕСС и размере повреждения.
Плюс за счёт пересчёта этих блоков из одного размера в другой на лету - больше вероятность возникновения ошибки.
пересчет фирмварью из физического номера 4К в виртуальный 512б до безобразия просто. Наделать ошибок в преобразование даже как-то трудно. Для этого талант нужен
Ну и ещё одно следствие большие потери на очень мелких файлах. Размером меньше размера блока. Хотя это и не актуально для 90 процентов пользователей - контент нынче крупный. Но средний кэш браузера с мелкими файлами мусора будет занимать в 2-3 раза больше места на диске с AF (4096 байт в секторе) чем на диске без AF (512 байт в секторе).
Compiller,
Ну и ещё одно следствие большие потери на очень мелких файлах.
все зависит от того какой размер кластера в файловой системы вы зададите. Все равно по умолчанию, пока что все винты эмулируют 512 байтные сектора.
Хотел купить рюкзак:Наделать ошибок в преобразование
Не в преобразовании - оно длится недолго, но делается постоянно, на это уходят микро/нано/пикосекунды, но это дополнительные команды и их много. А это увеличивает вероятность ошибки.
Хотя запись крупными блоками (в теории) увеличивает скорость и упрощает кэширование и адресацию.
Хотел купить рюкзак:все зависит от того какой размер кластера в файловой системы вы зададите. Все равно по умолчанию, пока что все винты эмулируют 512 байтные сектора.
На моих дисках с 512 байтными кластерами стоит размер кластера в 512 байт на NTFS, на FAT конечно всё не так радужно. Про остальные системы не скажу - не использую.
Compiller:но делается постоянно, на это уходят микро/нано/пикосекунды, но это дополнительные команды и их много. А это увеличивает вероятность ошибки.
Как у Вас ОС каждую секунду не падает И вообще грузится
на это уходят микро/нано/пикосекунды, но это дополнительные команды и их много.
главная проблема, где действительно теряется заметное время это запись. Запись блока менее 3584 байт, приводит к тому, что сначало надо прочитать сектор в буфер, а потом внести в буфер изменения и переписать целиком 4096 байт сектор. Главная проблема паразитные операции чтения. Если соблюдать правила по созданию разделов со смещением в 512 байтном выражении кратном 8, и не использовать кластер в файловой системе менее 4кб, то провала в производительности не будет.
Compiller,
На моих дисках с 512 байтными кластерами стоит размер кластера в 512 байт на NTFS, на FAT конечно всё не так радужно. Про остальные системы не скажу - не использую.
на AF винтах неважно, какая файловая система, кластер не должен быть менее 4кб, если не хотите получать резкое снижение производительности. Эмуляция 512 байтного сектора сделана для совместимости с любыми ОС и она не отменяет правила описанного выше. Потери пространства на мелких файлах естественно будут поболее, но если речь идет о менее чем миллионе файлов, то лучше пренебречь этими потерями.
Итого - пренебрегаем:
1. Надёжность - больше операций в разы производимых с вашими данными. В виде двойных , а то и тройных преобразований секторов.
2. Скорость - на все эти операции тоже нужно время.
3. Потери пространства - к примеру на банальном кэше браузеров.
И всё потому, что производитель (а начал бучу с AF как раз WD) решил получить больше места на старых пластинах.
Compiller,
1. Надёжность - больше операций в разы производимых с вашими данными. В виде двойных , а то и тройных преобразований секторов.
На надежность особо не повлияет. Практически одинаковая вероятность сбоя буферного ОЗУ или CPU на борту винта, что с 512 байтным сектором, что с 4096байтным. Прошу заметить, что пользовательские данные как таковые не преобразуются.
2. Скорость - на все эти операции тоже нужно время.
на обслуживание операций адресации тратится ничтожно малое время, которым можно пренебречь. Самые большие затраты по времени по мере убывания: непосредственно поиск нужного трека и сектора (учитывая достаточно скромную скорость вращения вала). Далее после операции чтения проверка прочитанного блока и соответствия ему ЕСС, анализ количества ошибок на предмет того не более ли их предельно допустимых, если ошибок не больше допустимого, то расчет позиций ошибок и расчет исправлений (как это делается можно почитать в теории БЧХ кодов). А процедура по представлению сектора в виде 8 секторов и тысячной доли от предыдущих операций не кушает. Т.е. величина настолько малая, что ее точно можно пренебречь.
3. Потери пространства - к примеру на банальном кэше браузеров.
уже много лет можно было говорить, что 99% пользователей под Win использовали в файловой системе размер кластера 4 и более кб. Посему изменение размера сектора для таких пользователей совсем не повлияло на экономию места. Пример с кешем браузера не совсем удачен в силу того, что многие браузеры уже давно не бросают в кеш тонны крошечных файликов. Дистанцируемся от браузеров. Представим, что стоит задача сохранить 100 000 мелких файлов менее 512 байт - Потери будут однозначно менее 400Мб. У каждого ли пользователя набертся такое количество файлов? Ну и если вдруг где-то набралось, то так ли страшно терять 400Мб от нескольки терабайт?
rtmaster:kode, а вы бы брали телик TOSHIBA который собирают у нас в РБ ?
И нафига тогда Toshiba в сравнении участвует вообще?
rtmaster, Настольные HDD Toshiba - бывшие Hitachi, а до того бывшие IBM. В Беларуси не производятся, и со времён IBM DTLA/AVER первых версий вроде без большинства детских болячек.
Хотя, правды ради, - винчестеры вообще в Беларуси не производятся.
HGST - Hitachi Global Storage technology - я в курсе.
https://en.wikipedia.org/wiki/HGST
Привет. Срочно помощь профи нужна)) попросили купить внешний hdd для подключения к ноуту и телику. посоветуйте плиз что-нибудь на 1 тб где-то за млн. смотрю вот эти модели http://catalog.onliner.by/externalhdd/seagate/stdr1000200
http://catalog.onliner.by/externalhdd/siliconpower/sp010tbphdd06s3k
http://catalog.onliner.by/externalhdd/seagate/stdr1000200
http://catalog.onliner.by/externalhdd/seagate/stdr1000203
офлайн
Адвокат_Дьявола
IRC Team
|
|
25913 |
20 лет на сайте Город:
|