Обратная совместимость технологий в ПК — безусловное благо. С её помощью пожилой процессор можно заставить работать в паре с оперативной памятью из «далёкого будущего», а новый накопитель без проблем приживается в древнем компьютере и делает его значительно быстрее даже с использованием старых версий интерфейса SATA.
И, если к legacy-коду можно относиться по-разному, то устаревшие протоколы и интерфейсы практически всегда уступают новым разработкам. Только вы об этом не узнаете, потому что новое железо в новом компьютере по умолчанию будет замедлено установками в пользу максимальной совместимости. Выясняем, какие настройки следует предпочесть, чтобы
UEFI — не «альтернативно одарённый BIOS», а лучший метод инициализации оборудования
На «железном» уровне новшества во взаимодействии платформы ПК с накопителями предельно понятны: жёсткие диски наращивали плотность записи и увеличили количество пластин в 3,5-дюймовом форм-факторе и наполнили особо ёмкие модели гелием, чтобы диски стали работать стабильнее. Будущее HDD отныне зависит от темпов внедрения технологии черепичной магнитной записи или более радикальным изменениям (рывку в объёме накопителей) с термоассистируемой магнитной записью.
SSD? Сменили несколько типов памяти, перестали быть роскошью в домашних компьютерах, нарастили объём до сотен гигабайт. Выжали все соки из SATA-III, заполучили скорости PCI-E и наконец заимели компактный форм-фактор.
Накопитель Kingston DCP-1000 — до 1 100 000 IOPS на чтение и 200 000 IOPS на запись, например
Но быстродействие накопителей зависит не только от «железа», но и программной составляющей. И здесь самое время вспомнить о BIOS, который задержался на сцене, словно закостеневшие на старости лет эстрадные кумиры.
Сегодня в сознании трудящихся UEFI — это такая красочная альтернатива «биосу», с градиентами, красивыми меню, поддержкой мыши и, иногда, русифицированным интерфейсов. Тем удивительнее, что пёстрый EFI (Extensible Firmware Interface, тогда ещё без Unified в аббревиатуре) изначальном варианте был разработан Intel ещё в далёком 2003 году. И изначально его предлагали для серверных Itanium как более гибкий и быстрый интерфейс для загрузки ОС и инициализации/диагностики комплектующих. Уж больно много слабых мест было в древнем 16-битном BIOS с 1 Мбайт адресуемой памяти, поэтому замена напрашивалась сама собой. Как это обычно бывает в соревновании слоев абстракции и производительности железа, UEFI стал «тяжелее» и превратился в мини-операционную систему с драйверами и службами, но быстродействие и стабильность того стоили.
В массовые компьютеры UEFI пришёл в 2012-2013 гг., а вместе с ним в «предзагрузочном» интерфейсе появились приятные и не очень, нововведения. Начнём с функции-«защитницы» Windows 8, Secure Boot.
Secure Boot — многострадальная защита от «посредников» между ОС и UEFI
В инициативе по внедрению функции Secure Boot в UEFI версии 2.2 и выше разработчики руководствовалась благими намерениями, если вы понимаете, о чём мы. То, что первыми на вооружение эту функцию взяли Microsoft (чтобы обезопасить запуск Windows 8 и «придушить» активиторы-бутлоадеры) — другой разговор.
Некоторое время только Windows 8 и умела загружаться в режиме Secure Boot, а пользователям всех других ОС приходилось отключать функцию в BIOS UEFI, потому что интерфейс отказывался исполнять неподписанные файлы не подготовленных соответствующим образом систем.
Принцип работы Secure Boot
«Мякотка» заключалась в том, что все новые компьютеры по требованию Microsoft поставлялись с включенным Secure Boot, поэтому о новой функции (в не очень приятных обстоятельствах «падающей» системы) вскоре узнали все любители отличных от Win 8 операционных систем. А в некоторых случаях обновление Microsoft просто «по приколу» активировало Secure Boot в UEFI даже в Windows 7, которая после такой имплантации благополучно «падала» при следующей загрузке. Это ещё одна разновидность «романтических» обстоятельств знакомства с новой функцией в былые годы.
«Я те покажу, что такое безопасная загрузка!», — как бы говорит нам обновление KB3133977 и включает неподдерживаемый на Windows 7 Secure Boot в материнских платах ASUS
Справедливости ради, стоит отметить, что современные дистрибутивы GNU/Linux (Ubuntu, Fedora, Red Hat и openSUSE в числе первых) достаточно быстро обзавелись подписью для загрузки в Secure Boot, но в 2016 году с подачи Microsoft индустрии этот стандарт дважды, скажем так, аукнулся.
Первый раз — когда редмондцы «потеряли» мастер-ключ от Secure Boot и скомпрометировали защиту, за внедрение которой так активно выступали. Не штатный ключ, а именно мастер-ключ, с которым во всех выпущенных устройствах при активном Secure Boot загрузчик становится «голым и беззащитным», а злоумышленники могут легко и просто подменить операционную систему на этапе первоначальной загрузки. Нет повести печальнее на свете, чем повесть о «золотых ключах» и дебагерских инструментах в широком доступе.
А второй раз Microsoft наделала шума, когда упомянутый выше бэкдор начали было применять во благо как средство «джейлбрейка» планшетов под управлением Windows RT. Дело в том, что эксперимент Microsoft с ARM-системами закончился провалом, а крутые и дорогие (когда-то) планшеты Surface не получили даже поддержки UWP-приложений. То есть, неплохие с конструктивной точки зрения устройства стали заложниками «мёртвой» операционной системы. А другой операционной системы в планшете быть не могло, ведь Secure Boot на планшетах, по требованию Microsoft, был неотключаемым. После того, как упомянутый выше бэкдор оказался общественным достоянием, пользователи ARM-версий Surface получили на некоторое время возможность запустить неавторизованный загрузчик и установить альтернативную ОС. Но патч-латка за авторством Microsoft подоспел до того, как «еретики» успели что-то предпринять.
У Microsoft Surface RT был шанс заполучить альтернативную ОС. К сожалению, не сбылось...
Словом, Secure Boot уже подводила производителей и пользователей ПК, и, есть риск, что это произойдёт снова, поэтому тех, кто сомневается в её полезности, можно понять. Использовать ли «защищённую загрузку» или нет — вопрос открытый, как и в случае с подходом «паранойя vs установленный антивирус», если речь идёт о Windows. По умолчанию в старых матплатах не-брендовых ПК эта опция отключена, однако слабая защита всё же лучше, чем никакая.
P.S. в рамках инициативы по «улучшению качества жизни» Microsoft добилась того, что Secure Boot может стать неотключаемым даже в десктопных ПК, выбор остаётся на совести производителя оборудования. Подписка пользовательских бинарных файлов обойдётся в $99.
Но бог с ними, с фичами безопасности, мы ведь здесь собрались ради настроек, которые ликвидируют «костыли» в работе накопителя? К ним и перейдём.
Устаревший и более медленный интерфейс по соображениям «кабы чего не вышло»
В списке устаревших технологий, которые гнездятся в новых матплатах ради совместимости со стандартами былых лет, неизменно фигурирует IDE (Integrated Drive Electronics) — режим контроллера накопителей, который не «ампутировали» из новых чипсетов только ради совместимости со старыми накопителями и ПО. В таком режиме накопители SATA 3.0 работают с быстродействием уровня своих PATA-предшественников.
А режим расширенного хост-контроллера (AHCI) даже в самых современных чипсетах отключен «до востребования». И напрасно, потому что только он сможет раскрыть потенциал современных накопителей при высокой нагрузке.
В былые времена загвоздка с использованием режим AHCI заключалась в том, что в операционных системах (Windows XP и Vista, по большей части) попросту не было драйверов для большинства AHCI-контроллеров в новых чипсетах, поэтому системы «падали в BSOD» сразу же после установки. Сегодня кулибины внедряют поддержку AHCI даже в эти две устаревшие системы, а уж Windows 7/8 и 10 поддерживают расширенный хост-контроллер в полной мере.
Накопитель в режиме последовательного чтения (IDE). Накопитель — Kingston SSD Now V+
Накопитель в режиме последовательного чтения (AHCI) (источник: dobreprogramy.pl)
От режима IDE AHCI отличает поддержка горячей замены накопителя (малополезно в домашнем ПК) и, что гораздо важнее, NQC. Native Command Queuing или «аппаратную установку очерёдности команд» часто считают новой разработкой для повышения быстродействия SSD, хотя на самом деле её разрабатывали ещё с учётом потенциала механических накопителей.
Поддержка NQC в режиме AHCI минимизирует движение головки в механических накопителях
NCQ «сортирует» команды при обращении к накопителю таким образом, чтобы минимизировать движения головки в HDD и как можно эффективнее использовать ячейки NAND в твердотельных накопителях. В случае с SSD режим AHCI важен ещё и для корректной работы TRIM и быстродействии на предельных для SATA-III скоростях (а в «потолок» SATA упираются даже недорогие накопители. Такие как Kingston UV400, например).
Режим AHCI жизненно важен для новых SATA-накопителей
Переключать режим работы контроллера желательно до установки операционной системы. Можно и после, но тогда придётся «заводить» AHCI с помощью нетрадиционной, понимаете ли, медицины. В любом случае, убедитесь, что ваши накопители используют для передачи данных современный интерфейс. Ведь гарантия того, что, например, Windows 98 сможет взаимодействовать с накопителем гораздо менее полезна, чем более высокое быстродействие в современных ОС и программах каждый день.
NTLDR is missing, если не используешь разметку GPT
Поддержка разметки GPT — ещё одна фича, которая стала повсеместно использоваться с приходом UEFI. Важная составляющая современных накопителей, и вот почему.
До прихода GUID Partition Table пользователям ПК приходилось довольствоваться архаичным методом размещения таблиц разделов — MBR или master boot record (главная загрузочная запись), стандарт образца 1983 года, ровесник DOS 2.0.
MBR — это такой сектор с загрузчиком операционной системы и информацией о логических дисках. Поддерживает работу с дисками объёмом до 2 Тбайт и только до четырёх основных разделов. Если 2-терабайтные HDD стали «бутылочным горлышком» в домашних ПК только недавно, то второй фактор породил трюки наподобие «расширенных разделов» ещё со стародавних времён.
GPT работает гораздо более гибко и присваивает каждому разделу глобальный идентификатор, поэтому разделов может быть неограниченное количество, а проблема взаимодействия с ёмкими накопителями перестаёт быть актуальной.
Загрузчик — всё
А главное — GPT гораздо более отказоустойчив, потому что загрузчик и информация о разделах больше не хранятся «в одной корзине». Если MBR повреждён — ваш накопитель впадает в «беспамятство», а информацию с него придётся восстанавливать долго и нудно. GPT хранит копии этой информации в разных секторах диска и восстанавливает информацию, если она повреждена.
В ёмких HDD разметка GPT стала суровой необходимостью, а новые операционные системы используют её даже для накопителей ёмкостью много меньше 2 Тбайт. Разумный принцип организации и надёжность GPT однозначно перевешивают её недостатки, да и с поддержкой проблем нет ещё со времён Windows 8 (GNU/Linux тоже не обделены поддержкой), поэтому конвертировать диски из формата MBR в его последователя будет не лишним.
Файловые системы: вы уже готовы к ReFS, а она к вам — нет
Файловая структура в ReFS
Дебютная версия «отказоустойчивой файловой системы» вышла в свет в бета-версиях Windows 8 и её серверных аналогах. Её будущее в домашних ПК пока туманно, тем более, в роли системного раздела, но ключевые наработки Microsoft в этом направлении известны уже сегодня. Среди них:
• Поддержка длинных имен. До 32768 символов в пути вместо 255, как это было в NTFS
• Устойчивость к перебоям в питании устройства. Данные и результаты изменений не будут повреждены, потому что файловая система оперирует метаданными и восстанавливает информацию в случае их повреждения. При любых операциях файловая система сначала создаёт новую копию метаданных в свободном пространстве, и только потом, в случае успеха, переводит ссылку со старой области метаданных на новую. Вот вам и сохранность файлов без журналирования.
• Избыточность хранения данных для большего ресурса накопителя.
• Более высокая скорость работы за счёт пониженной фрагментации.
ReFS ещё недостаточно отполирована для повсеместного внедрения, но если откуда-то и стоит ждать новшеств в методе хранения и оперирования файлами в Windows, то только отсюда.
Новое — значит лучшее?
Рекомендация выбирать самые новые протоколы и технологии из доступных была бы слишком наивной — всегда стоит взвешивать за и против, прежде чем расставлять галочки в UEFI или операционной системе. Но всё же стоит помнить о том, что в апгрейд старого компьютера — дело рук самих владельцев этого компьютера. ПК с многолетней выдержкой очень редко способен сконфигурировать новое железо правильным образом. А это значит, что после модернизации будет не лишним проверить, в каком режиме работает новая «железка» — хотя бы среди тех вариантов, о которых мы говорили сегодня. Заставляйте ваши SSD работать «на все деньги» при любом удобном случае!
Всякую новую вещь нужно уметь правильно использовать
Правильная конфигурация BIOS/UEFI и операционной системы — это хорошо, а когда она управляет новым быстрым железом — ещё лучше! Для всех любителей совмещать программную прокачку комплектующих с непосредственно апгрейдом мы дарим скидку 10% на SSD HyperX и память DDR4 в магазинах DNS и 10% скидки на накопители HyperX Fury и память DDR3 в Ситилинк! Акция действует с 21 марта по 4 апреля, это отличная возможность сделать свой компьютер быстрее и сэкономить.
А ещё мы рады сообщить, что вскоре обладателем нашей новейшей флагманской гарнитуры с объёмным звуком станет подписчик Kingston. Поэтому, если вы ещё не подписаны, нужно скорее исправлять ситуацию. :) Мы выберем победителя случайным образом и огласим
Подписывайтесь и оставайтесь с нами — будет интересно!
Для получения дополнительной информации о продукции Kingston и HyperX обращайтесь на официальный сайт компании. В выборе своего комплекта HyperX поможет страничка с наглядным пособием.
Комментарии (46)
CodeRush
28.03.2017 20:28+20Ребят, у вас весь рассказ про EFI получился из серии «слышал звон, нагуглил новостей, теперь мнение имею»:
— никакой мастер-ключ у МС не утекал, иначе его давно уже заменили бы (утек подписаный кусок загрузчика, который позволял загрузить по цепочке что угодно только на ARM, и был затем успешно забанен добавлением хешей в переменную dbx).
— проблемы с Windows 7 у ASUS возникли потому, что ASUS до сих пор грубо нарушает спецификацию, позволяя включать SecureBoot вместе с CSM, что не имеет никакого смысла.
— чтобы бы там в MS не говорили, пока жив CSM, на десктопных системах всегда будет возможность отключения SecureBoot, потому что иначе CSM нормально не реализовать.
Если вам интересно, как работал SecureBoot во времена UEFI 2.4 - вот моя практическая статья о нем. С тех пор внесли немного изменений, добавив режим аудита для того, чтобы не мучатся с подписыванием ОРОМов доверенных устройств, но суть осталась та же.
В этой же статье вот это «введение в EFI» не нужно совершенно, потому что режим AHCI (вместо устаревшего native IDE и еще более древнего legacy IDE) появился раньше UEFI и не имеет к нему отношения, а GPT для EFI не является обязательным типом разметки. Написали бы лучше про необходимость драйвера NvmExpressDxe для загрузки с NVMe-накопителей и про опыт добавления этого драйвера в прошивку / загрузки его с ESP в случае, если прошивка старая и об NVMe еще ничего не знает.
silico
28.03.2017 20:37насколько мне помнится, был косяк с разметкой дисков под mbr.и gpt. они не бились в один сектор на 512б. через это контроллер лог запись 4к читал дважды в 2секторах. вендоры делали утилиты, к выравнивали разделы (начало раздела) на на физический 4к. как то так, навскидку).
я с 2009 г пользуюсь symon (разраб называет его монитор ос, как по мне, так точнее было бы монитор разделов) так вот он позволяет под mbr бить диск в скока) хошь разделов (primary)и грузица с них на выбор в любом сочетании, это первое, и второе — физически правильно бить разделы на 64/255/0 сек, дорожка, цилиндр.
CaptainFlint
28.03.2017 20:48+1насколько мне помнится, был косяк с разметкой дисков под mbr.и gpt. они не бились в один сектор на 512б. через это контроллер лог запись 4к читал дважды в 2секторах.
Это вы перепутали с дисками в Advanced Format. К MBR/GPT отношения не имеет. Просто физический сектор у современных дисков 4 Кб, а программы за долгое время успели завязаться на сектор в 512 б, плюс древняя схема выравнивания разделов по цилиндрам (давно не актуальная, но соблюдающаяся «по привычке»), плюс то, что число цилиндров не является степенью двойки. В итоге выравнивание раздела по цилиндру приводило к тому, что он не был выровнен по физическим секторам.silico
28.03.2017 21:35вот старые диски, не af, и не бились в 512б под gpt, когда первый раздел начинается с lba 34, т.е перед ним 33
CaptainFlint
28.03.2017 22:55Сама GPT занимает 34 сектора (точнее, 1 сектор — protective MBR + 33 сектора на GPT), поэтому перед первым разделом не может быть менее 34 секторов. А за этими пределами создавать можно что угодно и как угодно, формат GPT просто содержит LBA-номер сектора (512-байтного). Можно создать по границе 4-килобайтного блока, а можно создать со смещением. Всё точно так же, как и в MBR (при использовании LBA-адресации). Это уже вопрос не к формату таблицы разделов, а к конкретным инструментам разбиения диска. Ну и к тому пользователю, который это разбиение выполняет, разумеется.
silico
28.03.2017 23:31еще раз — первый раздел начинается на lba34
https://ru.m.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%BE%D0%B2_GUIDCaptainFlint
28.03.2017 23:56+3Нумерация с нуля. LBA 34 означает, что перед этим сектором находятся не 33, а 34 сектора (с номерами от 0 до 33).
И никто не заставляет создавать первый раздел прямо вот строго сразу за таблицей разделов. Современные разбивальщики вообще выравнивают по мегабайтам, что даёт почти мегабайтную дыру перед первым разделом, и ничего. Так что выровнять раздел просто, было бы желание.
CaptainFlint
28.03.2017 20:41+2GPT работает гораздо более гибко и присваивает каждому разделу глобальный идентификатор, поэтому разделов может быть неограниченное количество…
Использование глобального идентификатора никак не связано с неограниченностью числа разделов. MBR тоже спокойно может хранить бесконечное число логических разделов без всяких там идентификаторов — тупой односвязный список, с чего бы ему ограничиваться. Но во многих программах зашит лимит на 128 разделов (что для MBR, что для GPT), поэтому, несмотря на неограниченность по спецификации, я бы не рекомендовал превышать этот лимит. Впрочем, большинству пользователей так много и не нужно.
GPT хранит множество копий этой информации в разных секторах диска и восстанавливает информацию, если она повреждена.
Вообще-то, не «множество», а две. Одна в начале диска, одна в конце.
Shapeshifter
28.03.2017 21:14+3Устаревший и более медленный интерфейс по соображениям «кабы чего не вышло»
не очень удачный пример: на картинках в данном паттерне разница скорости IDE vs ACHI менее 10%…
VBKesha
28.03.2017 23:12Могу сейчас ляпнуть чушь, но насколько мне известно сами диски про AHCI ничего как не знали так и не знают. У них своя система команд. А AHCI уже реализовано на отдельном контроллере/материнской плате и является прослойкой между командами диску и OS. И эти 10% он и добавляет благодаря всяким ускоряющим аппаратным штукам.
h31
29.03.2017 08:45Да, всё так и есть. Если быть чуточку точнее, режим IDE эти «штучки» просто не позволяет использовать, а AHCI наоборот, раскрывает. Как в программах — есть устаревший ограниченный API, с которым нужно поддерживать совместимость, и более полный современный интерфейс, хотя в обоих случаях по сути выполняется один и тот же код.
А тесты на картинке просто неправильно сделаны. Если бы взяли тесты на IOPS-ы, сразу бы стало видно, кто есть кто. У меня есть диски, которые подключены по USB 2.0, и там тоже не поддерживается очередь команд. Стоит хотя бы к двум файлам одновременно обратиться, и начинаются дикие тормоза :(
MagicEx
28.03.2017 21:16+232768 символов в пути NTFS прекрасно поддерживает, ограничение на стороне Windows (уже можно отключить в Win10\Server2016). Впрочем можно обратиться к таким файлам через \?\\.
Про скорость накопителя ровно один абзац, относящийся к IDE\AHCI.
Остальное — про безопасность и надежность.
Так почему накопитель не едет то? )
Dee3
28.03.2017 21:37+1Избыточность хранения данных для большего ресурса накопителя.
Ой ли?
Также не раскрыт вопрос драйверов msahci vs intel RST, и на каких драйверах интересно тестирует сам производитель и что рекомендует?
GennPen
28.03.2017 21:51А режим расширенного хост-контроллера (AHCI) даже в самых современных чипсетах отключен «до востребования».
Не знаю какого года у вас «современные», но все последние материнские платы которые видел — у всех по умолчанию AHCI включен.
Wernisag
29.03.2017 13:12Если чипсет H61 можно считать современным, то матери от Gigabyte идут с включенным по умолчанию с IDE
Taciturn
28.03.2017 22:52В таком режиме накопители SATA 3.0 работают с быстродействием уровня своих PATA-предшественников.
И скриншот из которого видно что разница всего 13.5 мегабайт. Что конечно не 0, и на более новых носителях может быть больше, но крайне далеко от ваших страшилок.
GPT хранит копии этой информации в разных секторах диска и восстанавливает информацию, если она повреждена.
А это где-то действительно так работает? Прямо сейчас попробовал на W10 — стёр копию GTP в начале диска и всё, диск пустой, никакого автовосстановления.
Вручную восстановить конечно можно, несколько легче чем с MBR. Но и с MBR совсем не сложно.
Не то чтобы GPT плох, но и смысла конвертировать из MBR уже имеющийся диск никакого.VBKesha
28.03.2017 23:19И скриншот из которого видно что разница всего 13.5 мегабайт. Что конечно не 0, и на более новых носителях может быть больше, но крайне далеко от ваших страшилок.
Я не так давно замерял на SSD скорость в
AHCI:
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 32.311 s, 358 MB/s
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 32.3014 s, 358 MB/s
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 32.3107 s, 358 MB/
IDE:
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 33.3194 s, 347 MB/s
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 33.3228 s, 347 MB/s
root@xubuntu:/home/xubuntu# dd if=/dev/sdb of=/dev/zero bs=1M count=11024
11024+0 records in
11024+0 records out
11559501824 bytes (12 GB, 11 GiB) copied, 33.3727 s, 346 MB/s
В общем то с увлечением скорости диска видимо не сильно меняется разница между ACHI и IDE тебе 11-12 мегабайт.
DistortNeo
29.03.2017 01:28Ну с 1-мегабайтным блоком любой сможет. Было бы интересно посмотреть на скорость при работе с блоками меньшего размера, а лучше вообще со случайным доступом.
dd if=/dev/sdb of=/dev/zero bs=512 count=11024 dd if=/dev/zero of=/dev/zero bs=512 count=11024
VBKesha
29.03.2017 10:33По скорости разницы никакой.
Gendalph
29.03.2017 14:24Должна быть разница не в скорости, а в latency и IOPS.
Taciturn
29.03.2017 15:06Вполне вероятно что разница будет. Но в статье про это ни слова, только абстрактные страшилки и скриншоты демонстрирующие отсутствие заметной на глаз разницы.
Gendalph
30.03.2017 02:07@Kingston_Technology, прошу выслать мне на тест один из ваших дисков — обещаю сесть и непредвзято рассмотреть его производительность в зависимости от настроек. /полушутка
alexws54tk
29.03.2017 11:33
Это как? Вести запись в устройство, которое только и умеет, что отдавать на выход нули.# dd … of=/dev/zero …
Может имелось в видуdd … of=/dev/null …
% dd if=/dev/zero bs=512 count=22M of=/dev/null 23068672+0 записей получено 23068672+0 записей отправлено 11811160064 байт (12 GB, 11 GiB) скопирован, 6,22619 s, 1,9 GB/s # Конечно не SSD, но AHCI включен % dd if=/dev/sda bs=512 count=22M of=/dev/null 23068672+0 записей получено 23068672+0 записей отправлено 11811160064 байт (12 GB, 11 GiB) скопирован, 133,262 s, 88,6 MB/sVBKesha
29.03.2017 11:50Ну при записи в /dev/zero ничего не происходит, также как и при записи в /dev/null
Хотя правильней наверно всё же будет /dev/null но на практике отсутствие разницы.
в данном примере тоже обычный HDD:
dd if=/dev/sda of=/dev/null bs=512 count=20000000
20000000+0 records in
20000000+0 records out
10240000000 bytes (10 GB) copied, 46,0533 s, 222 MB/s
dd if=/dev/sda of=/dev/zero bs=512 count=20000000
20000000+0 records in
20000000+0 records out
10240000000 bytes (10 GB) copied, 45,8982 s, 223 MB/s
alcr
29.03.2017 11:05+1Поддержка длинных имен. До 32768 символов в пути вместо 255, как это было в NTFS
NTFS поддерживает длинные имена если не с рождения, то очень-очень давно, как минимум со времён NT4sp6. Ограничение на 255 символов — это ограничение древнего винапи, которое обходится либо использованием новых функций и интерфейсов, либо костылём "\\?\C:\путь_любой_длины".CaptainFlint
29.03.2017 12:14alcr
29.03.2017 12:27Хм, действительно.
Но это, имхо, полная фигня. Делать имя файла такой длины — очень сомнительная затея. А вот старое ограничение в MAX_PATH символов на полный путь с именем файла — вот это истинный маразм, который до сих пор живее всех живых.CaptainFlint
29.03.2017 12:49Проблема-то не в системе, а в программах. Если убрать ограничение в API, то куча программ порушатся из-за того, что используют фиксированный буфер и не проверяют длину полученной строки.
Впрочем, в десятке что-то там такое, вроде, собирались уже делать в этом направлении. Ключом реестра что ли включается…DistortNeo
29.03.2017 13:03А если ограничение не убрать, то программисты так и будут лепить фиксированный буфер.
Кстати, раньше программы работали только с именами в формате 8.3, но это не помешало ввести длинные имена, сделав временный костыль (короткий алиас для длинных имён).
CaptainFlint
29.03.2017 14:05Короткие имена — это всё же наследие 16-битной эры. Первая 32-битная винда (95) шла уже с длинными именами, так что всё, что под неё писалось, должно было это учитывать. Сейчас такого крупного архитектурного изменения не планируется, чтобы туда можно было под шумок MAX_PATH=32768 пропихнуть. Вместо этого сделали манифестом — что ж, посмотрим, к чему это приведёт.
sumanai
29.03.2017 16:37сделав временный костыль (короткий алиас для длинных имён).
Код этого «временного» костыля жив и в десятке, ни байта не изменили со времён XP, в XP отличия от Win2000 только в одном сраврении, а у Win2000 отличия от NT4 только в порядке следования функций в исходном коде.
Да, я проверял.
Insane11
29.03.2017 19:28IDE (Integrated Development Environment)
Наверное, должно быть так — IDE (англ. Integrated Drive Electronics — «электроника, встроенная в привод»)
NaHCO3
30.03.2017 09:11-3Как-то у вас всё поверхностно описано, хотя темы сложные и неоднозначные. А вы их только с одного угла рассматриваете, да и то половина предмета в кадр не попадает.
BIOS и UEFI. Вы говорите UEFI лучше, но забыли сказать чем. Вообще, всё новое лучше старого, иначе его бы не придумывали — это само собой подразумевается. Но интересно в чём точно заключается преимущество. UEFI решает одну проблемку в загрузке компьютера — двойную инициализацию. Сначала биос загружался и инициализировал железо (в режиме совместимости), потом передавал управления операционной системе, и она начала инициализировало всё железо наново (уже в безопасном режиме — с разнесением полномочий ring0-ring3 и т.п.)
В теории ускорение загрузки, упомянутое вами, достигается за счёт отказа от двойной инициализации. UEFI передаёт железо готовой к использованию в ОС. На практике, это работает только если UEFI заточен для работы с этой ОС. Догадайтесь для какой именно ОС заточен UEFI? Кто протащил его через монопольный сговор? Так вот — для линукса быстрее загружаться через традиционный BIOS, просто потому что он проще и быстрее стартует сам по себе, а двойной инициализации не избежать. Для линукса есть свой UEFI, называется coreboot, но совместимого с ним железа очень мало, и оно дико устаревшее. Так что для линуксоидов от UEFI один вред, и они ваших восторгов не разделяют.
По поводу Secure Boot — у меня он никогда не заведётся, потому что я использую gentoo, систему собираю сам, и мне никто не подпишет. Линукс, конечно, гибкая система — никто не мешает мне загрузить подписанное ядро и сделать из него kexec — но зачем мне такой геморрой? Если бы производитель железа действительно заботился о пользователе, он бы дал ему возможность подписывать образа для своей системы. А он заботится только о том, чтобы ярмо покрепче нацепить на покупателя.
NCQ — полезная примочка, но не обязательная. Все средства для разметки дисков как раз для этого и задают архитектуру — бьют диски на сектора и дорожки вместо цельной адресации, чтобы операционная система могла сама оптимально упорядочивать запросы к диску. Но с тех пор как появились жёсткие диски, которые и не диски вовсе, а штабеля флеш памяти, разложенные каждым производителем в свой уникальный пасьянс, NCQ стал более актуален.
Преимущества GPT перед MBR очевидны, но в некоторых ситуациях достаточно и MBR, и нечего лишнюю память занимать. Если 4 разделов и 2х терабайтов вам за глаза — возьмите MBR, она работает, подтверждено годами. Восстановить данные можно, если вы помните размер разделов. А ещё можно и по характерным заголовкам файловых систем поискать. Надёжно от битых дисков спасает только бекап — всё прочее относительно.
А если вы ещё сами не знаете, сколько разделов вам понадобится — то тут и GPT не поможет. Надо сразу ставить LVM или какую-нибудь BTRFS, которая в себя включает функциональность управления разделами, в виде сабвольюмов. Прям поверх диска, без MBR или GPT — они уже морально устарели, если вам действительно нужна гибкая работа с разделами.NaHCO3
30.03.2017 09:17Да, забыл сказать. GPT и MBR могут работать одновременно. Это не рекомендуется, но никто не мешает с помощью небольшого извращения создать диск, который будет размечен одновременно и MBR и GPT. Очень помогало в начальный этап внедрения GPT, когда его поддерживала только половина софта, а вторая ничего про него не слышала.
CodeRush
30.03.2017 10:08+1Отличный пост, почти все мифы об UEFI, в которые верят апологеты Linux, точно также начитавшиеся новостей, как и автор этой статьи.
Давайте по порядку: UEFI не решает проблему двойной инициализации ни на одной платформе, потому что создан был вовсе не для этого. EFI, вообще говоря — это просто интерфейс между прошивкой и ОС, и он не имеет никакого отношения к инициализации оборудования вообще, а пришел на смену интерфейса BIOS interrupt call, потому что для той платформы, для которой EFI изначально разрабатывался Intel с 1998 года (назывался он тогда Intel Boot Initiative) — IA64/Itanium совместимость с legacy BIOS реализовывать не стали из за отсутсвия поддержки 16-битного режима исполнения.
Еще раз: UEFI — это всего лишь интерфейс между ОС и прошивкой, избавленый от костылей вроде ресета через IO-порт клавиатуры и управления адресной линией A20.
То, что вы называете UEFI на деле представляет из себя комбинацию из двух относительно независимых компонентов: кода инициализации оборудования и кода, реализующего интерфейс с ОС. На большинстве современных ПК инициализацией оборудования теперь занимается либо Intel PI, либо AMD AGESA, либо вышеупомянутый coreboot, а на ARMах — uboot.
Еще раз: coreboot занимается только инициализацией оборудования, а для предоставления интерфейса с ОС ему нужен т.н. payload, который может реализовать как старый интерфейс BIOS int (SeaBIOS), так и более новый интерфейс UEFI (TianoCore), а может вообще никакого не реализовавывать и запускать ядро Linux напрямую.
Для какой ОС заточен UEFI — ни для какой, активно используется MacOS и Windows. Кто протащил его через монопольный сговор — Intel, начав предоставлять MRC в виде 32-битного блоба (который с 16-битным BIOS нужно было женить через жертвоприношения и танцы с бубном и барабанами), а потом вынудив IBV перейти на UEFI с релизом Sandy Bridge. Apple же использует EFI с 2007 года, потому что на момент перехода на x86 никаких альтернатив EFI на x86 не было уже тогда.
Про SecureBoot — вы можете подписывать все свое своими собственными ключами, и никто вам не мешает этой возможностью пользоваться, а не рассказывать очередной раз про ярмо, которое на пользователя якобы кто-то нацепил.
Линуксоиды, если вы хотите хоть немного разобраться прежде чем начинать в очередной раз обвинять производителей железа и ОС во всех смертных грехах, прочтите Beyond BIOS, авторы которой этот самый UEFI придумали и поддерживают уже почти 20 лет.NaHCO3
30.03.2017 19:39Я действительно не сильно разбирался в технологии, зачем читать документацию, если ты всё равно не собираешься ей пользоваться. Всё что я знаю — это сумма статей вендоров, в которых они объясняют, зачем мне надо поставить себе UEFI и быть довольным.
Вот например, в этой статье сказано, что UEFI ускоряет загрузку. А вы утверждаете, что UEFI вовсе этого не делает. Что всё его предназначение — это замена специальных вызовов биоса, которым современные ОС всё равно никогда не пользовались, предпочитая отдавать работу с железом своим собственным драйверам.
За ссылку на SecureBoot спасибо — добавил себе в закладки. До сих пор думал, что без джейлбрейка ты не заставишь его кушать другие ключи.
trojan218
30.03.2017 09:33-1Уважаемые при всё уважение, у вас акции очень короткие и попадают в промежуток между получками(ЗП), у вас менеджеры этот вариант рассматривали при рассмотрение рамок продаж, по моему ( частное мнение), актуальные даты это 5-15 и 20-30 числа. А так же хорошая практика предупреждать о грядущих акциях, может у кого-то другие временные рамки получки ( те кто работают сами на себя или выполняют работу на заказ)
GennPen
Так почему новый быстрый накопитель даёт сбой и «не едет» после апгрейда? Может быть брак?