Что такое драйвер хранилища
Один из основных способов доступа к данным в хранилище Azure Data Lake Storage 2-го поколения связан с использованием файловой системы Hadoop. В Data Lake Storage 2-го поколения пользователи хранилища BLOB-объектов Azure могут получить доступ к новому драйверу, драйверу файловой системы BLOB-объектов Azure или ABFS . ABFS является частью Apache Hadoop и входит во многие коммерческие дистрибутивы Hadoop. При использовании этого драйвера многие приложения и платформы могут получить доступ к данным в хранилище BLOB-объектов Azure2 без какого-либо кода, явно ссылающегося на Data Lake Storage 2-го поколения.
Предыдущая возможность: драйвер Windows Azure Storage Blob
Драйвер Windows Azure Storage Blob или WASB предоставлял оригинальную поддержку хранилища BLOB-объектов. Этот драйвер выполнял сложную задачу сопоставления семантики файловой системы (как это требуется интерфейсом файловой системы Hadoop) с семантикой интерфейса стиля хранилища объектов, предоставляемого хранилищем BLOB-объектов Azure. Этот драйвер продолжает поддерживать эту модель, обеспечивая высокопроизводительный доступ к данным, хранящимся в больших двоичных объектах. Проблема заключается в том, что для этого сопоставления используется значительный объем кода, что затрудняет его техническое обслуживание. Кроме того, при некоторых применяемых к каталогам операциях, таких как FileSystem.rename() и FileSystem.delete(), требуется, чтобы драйвер выполнил большое количество операций (из-за того, что объекты хранилища не поддерживают каталоги), что часто приводит к снижению производительности. Драйвер ABFS разработан для преодоления присущих WASB недостатков.
Драйвер файловой системы больших двоичных объектов Azure
Интерфейс REST хранилища Azure Data Lake Storage поддерживает семантику файловой системы с помощью хранилища BLOB-объектов Azure. Учитывая, что файловая система Hadoop предназначена для поддержки той же семантики, сложное сопоставление в драйвере не требуется. Таким образом, драйвер файловой системы больших двоичных объектов Azure (или ABFS) является простой оболочкой клиента для интерфейса REST API.
Однако существуют некоторые функции, которые драйвер все же должен выполнять:
Схема URI для ссылки на данные
Применяя вышеуказанный формат URI, стандартные инструменты и платформы Hadoop могут использоваться для ссылки на эти ресурсы:
На внутреннем уровне драйвер ABFS преобразует ресурсы, указанные в URI, в файлы и каталоги и вызывает REST API хранилища Azure Data Lake Storage с использованием этих ссылок.
Аутентификация
Драйвер ABFS поддерживает две формы проверки подлинности, поэтому приложение Hadoop может безопасно обращаться к ресурсам, содержащимся в учетной записи, совместимой с Data Lake Storage 2-го поколения. Дополнительные сведения о схемах проверки подлинности приведены в Руководстве по безопасности службы хранилища Azure. К ним относятся:
Общий ключ позволяет пользователям получать доступ ко всем ресурсам в учетной записи. Ключ шифруется и сохраняется в конфигурации Hadoop.
Токен носителя OAuth Azure Active Directory. Токен носителя Azure AD приобретается и обновляется с помощью драйвера, используя либо идентификатор пользователя, либо настроенный субъект-службу. С помощью этой модели проверки подлинности доступ разрешен для каждого вызова, использующего идентификатор, который связан с предоставленным токеном и оценивается с помощью назначенного списка управления доступом POSIX (ACL).
Azure Data Lake Storage 2-го поколения поддерживает только конечные точки Azure AD версии 1.0.
Конфигурация
Все настройки драйвера ABFS хранятся в файле конфигурации core-site.xml . В дистрибутивах Hadoop с Ambarі конфигурацией также можно управлять с помощью веб-портала или REST API Ambari.
Подробная информация обо всех поддерживаемых элементах конфигурации указана в официальной документации по Hadoop.
Драйверы хранилища Docker контролируют, как изображения и контейнеры хранятся в вашей файловой системе. Это механизм, который позволяет вам создавать изображения, запускать контейнеры и изменять доступные для записи слои. Вот различия между каждым драйвером и ситуациями, в которых их следует использовать.
Для чего нужны драйверы хранилища?
Драйвер активного хранилища определяет, как Docker управляет вашими изображениями и контейнерами. Доступные драйверы реализуют различные стратегии обработки слоев изображений. У них будут уникальные характеристики производительности в зависимости от используемого сценария хранения.
Драйверы хранилища внутренне связаны с «доступным для записи слоем» контейнера. Этот термин относится к самому верхнему уровню файловой системы контейнера, который вы можете изменять, выполняя команды, записывая файлы и добавляя программное обеспечение во время выполнения.
Хотя постоянные данные контейнера Docker всегда должны храниться в томах, изменения в собственной файловой системе контейнера часто неизбежны. Возможно, вы записываете временные файлы, сохраняете переменные среды в файл конфигурации или кэшируете данные для дальнейшего использования.
Все эти операции приводят к тому, что файловая система работающего контейнера отличается от той, которая определена его образом. Выбранный вами драйвер хранилища устраняет несоответствие и учитывает разницу.
Что происходит, когда вы запускаете контейнер?
Когда запускается новый контейнер, Docker сначала извлекает слои изображения, созданные путем построения его файла Dockerfile. Слои сохраняются на вашем хост-компьютере, поэтому вам не нужно снова загружать изображение, пока вы не захотите получить обновления. В рамках процесса извлечения Docker идентифицирует и повторно использует слои, которые у него уже есть, избегая избыточных загрузок.
Как только слои изображения станут доступны, Docker запустит контейнер и добавит сверху дополнительный слой. Это доступный для записи уровень, который может изменять контейнер. Все нижние уровни неизменяемы и являются производными от их определений Dockerfile.
Слой с возможностью записи хорошо работает с небольшими накладными расходами, когда вы просто добавляете файлы в файловую систему контейнера. Они попадают в слой с возможностью записи наверху стека. Однако изменения в существующие файлы вызывают больше проблем: они существуют на нижних уровнях, доступных только для чтения, но теперь в них нужно записывать.
Подход Docker заключается в «копировании при записи», то есть файл копируется из исходного слоя в доступный для записи уровень в момент модификации. Это операция с интенсивным вводом-выводом, которая может привести к снижению производительности.
Различные драйверы хранилища несут ответственность за реализация поддержки копирования при записи. Каждый драйвер предлагает уникальный компромисс между производительностью и эффективностью использования диска.
Доступные драйверы хранилища
Вот краткое изложение возможных вариантов.
overlay2
Драйвер overlay2 теперь используется по умолчанию во всех активно поддерживаемых дистрибутивах Linux. Для этого требуется резервная файловая система ext4 или xfs.
overlay2 предлагает хороший баланс между производительностью и эффективностью для операций копирования при записи. Когда требуется копирование при записи, драйвер просматривает слои изображения, чтобы найти нужный файл, начиная с самого верхнего слоя. Результаты кешируются, чтобы ускорить процесс в следующий раз.
Как только файл найден, он копируется на доступный для записи уровень контейнера. Затем копия модифицируется с изменениями, запрошенными контейнером. С этого момента контейнер видит только новую скопированную версию файла. Оригинал в нижнем слое изображения становится непрозрачным для контейнера.
overlay2 работает на уровне файлов, а не на уровне блоков. Это повышает производительность за счет максимальной эффективности использования памяти, но может привести к увеличению доступных для записи слоев при внесении большого количества изменений.
Альтернативы этому драйверу включают aufs и более старый оверлей. Ни один из них не рекомендуется для использования в современных дистрибутивах Linux, где поддерживается overlay2.
btrfs и zfs
Эти два драйвера работают на уровне блоков и идеально подходят для операций с интенсивной записью. Каждому из них требуется соответствующая резервная файловая система.
Использование этих драйверов приводит к тому, что ваш каталог / var / lib / docker хранится на томе btrfs или zfs. Каждый слой изображения получает свой собственный каталог в папке вложенных томов. Пространство выделяется каталогам по требованию по мере необходимости, что позволяет поддерживать низкий уровень использования диска до тех пор, пока не будут выполнены операции копирования при записи.
Базовые слои изображения хранятся в файловой системе в виде подтомов. Другие слои становятся снимками, содержащими только те различия, которые они вносят. Изменения записываемого уровня обрабатываются на уровне блоков, добавляя еще один снимок с экономией места.
Вы можете создавать снимки подобъектов и другие снимки в любое время. Эти моментальные снимки продолжают обмениваться неизмененными данными, сводя к минимуму общее потребление памяти.
накладки-предохранители
Этот драйвер хранилища позволяет запускать Docker в режиме без root на компьютере, на котором отсутствует поддержка драйвера overlay2. Однако, поскольку все текущие целевые дистрибутивы Linux теперь работают с overlay2, fuse-overlayfs больше не требуется и не рекомендуется.
Этот водитель работает путем реализации наложенной файловой системы с помощью FUSE. Как файловая система пользовательского пространства, она работает в режиме без root, но снижает производительность по сравнению с системой хранения на уровне ядра.
Драйвер vfs включен только в целях тестирования и не должен использоваться в производственной среде. Документально подтверждена низкая производительность этого драйвера.
vfs может быть полезен в некоторых особых сценариях, поскольку он не использует копирование при записи. Вместо этого каждый уровень получает свой собственный каталог на диске. Когда файлу нужно перемещаться между слоями, он просто копируется в новый каталог.
Следовательно, vfs работает со всеми файловыми системами и выигрывает от простоты и легкости проверки. Он страдает от интенсивного ввода-вывода и склонности к высокой загрузке диска, поскольку каждое изменение файла запускает полную копию с исходного уровня.
devicemapper
Резюме
Драйверы хранилища Docker используются для управления слоями изображений и доступной для записи частью файловой системы контейнера. Хотя изменения файловых систем контейнера теряются при остановке контейнера, они все равно должны сохраняться во время работы контейнера. Этот механизм обеспечивает драйвер хранилища.
Каждый драйвер обладает различным набором оптимизаций, что делает его более или менее подходящим для разных сценариев. В настоящее время overlay2 является драйвером по умолчанию и рекомендуемым вариантом для большинства рабочих нагрузок, хотя альтернативные варианты, такие как btrfs, zfs и fuse-overlayfs, имеют некоторые более продвинутые функции и могут потребоваться в определенных случаях.
Как уважаемый хабрапользователь наверняка знает, «драйвер устройства» — это компьютерная программа управляющая строго определенным типом устройства, подключенным к или входящим в состав любого настольного или переносного компьютера.
Основная задача любого драйвера – это предоставление софтового интерфейса для управления устройством, с помощью которого операционная система и другие компьютерные программы получают доступ к функциям данного устройства, «не зная» как конкретно оно используется и работает.
Обычно драйвер общается с устройством через шину или коммуникационную подсистему, к которой подключено непосредственное устройство. Когда программа вызывает процедуру (очередность операций) драйвера – он направляет команды на само устройство. Как только устройство выполнило процедуру («рутину»), данные посылаются обратно в драйвер и уже оттуда в ОС.
Любой драйвер является зависимым от самого устройства и специфичен для каждой операционной системы. Обычно драйверы предоставляют схему прерывания для обработки асинхронных процедур в интерфейсе, зависимом от времени ее исполнения.
Любая операционная система обладает «картой устройств» (которую мы видим в диспетчере устройств), для каждого из которых необходим специфический драйвер. Исключения составляют лишь центральный процессор и оперативная память, которой управляет непосредственно ОС. Для всего остального нужен драйвер, который переводит команды операционной системы в последовательность прерываний – пресловутый «двоичный код».
Как работает драйвер и для чего он нужен?
Основное назначение драйвера – это упрощение процесса программирования работы с устройством.
Он служит «переводчиком» между хардовым (железным) интерфейсом и приложениями или операционными системами, которые их используют. Разработчики могут писать, с помощью драйверов, высокоуровневые приложения и программы не вдаваясь в подробности низкоуровневого функционала каждого из необходимых устройств в отдельности.
Как уже упоминалось, драйвер специфичен для каждого устройства. Он «понимает» все операции, которые устройство может выполнять, а также протокол, с помощью которого происходит взаимодействие между софтовой и железной частью. И, естественно, управляется операционной системой, в которой выполняет конкретной приложение либо отдельная функция самой ОС («печать с помощью принтера»).
Если вы хотите отформатировать жесткий диск, то, упрощенно, этот процесс выглядит следующим образом и имеет определенную последовательность: (1) сначала ОС отправляет команду в драйвер устройства используя команду, которую понимает и драйвер, и операционная система. (2) После этого драйвер конкретного устройства переводит команду в формат, который понимает уже только устройство. (3) Жесткий диск форматирует себя, возвращает результат драйверу, который уже впоследствии переводит эту команду на «язык» операционной системы и выдает результат её пользователю (4).
Как создается драйвер устройства
Для каждого устройства существует свой строгий порядок выполнения команд, называемой «инструкцией». Не зная инструкцию к устройству, невозможно написать для него драйвер, так как низкоуровневые машинные команды являются двоичным кодом (прерываниями) которые на выходе отправляют в драйвер результат, полученный в ходе выполнения этой самой инструкции.
При создании драйвера для Линукса, вам необходимо знать не только тип шины и ее адрес, но и схематику самого устройства, а также весь набор электрических прерываний, в ходе исполнения которых устройство отдает результат драйверу.
Написание любого драйвера начинается с его «скелета» — то есть самых основных команд вроде «включения/выключения» и заканчивая специфическими для данного устройства параметрами.
И чем драйвер не является
Часто драйвер устройства сравнивается с другими программами, выполняющими роль «посредника» между софтом и/или железом. Для того, чтобы расставить точки над «i», уточняем:
- Драйвер не является интерпретатором, так как не исполняется напрямую в софтовом слое приложения или операционной системы.
- Драйвер не является компилятором, так как не переводит команды из одного софтового слоя в другой, такой же.
Ну и на правах рекламы – вы всегда знаете, где скачать новейшие драйвера для любых устройств под ОС Windows.
Раз уж в нашем предыдущем посте мы пригласили всех желающих поучаствовать в добровольной помощи в разработке очередных версий DRP, сегодня пришла пора рассказать о том, как именно мы создаем немаловажную вещь при работе с большими архивами драйверов (необходимые сис. админам и другим профессионалам, занимающимся «серийной» настройкой компьютеров) — индексы.
У каждого пользователя на локальном компьютере собирается индекс всех драйверов, присутствующих в системе – в том числе и самой операционной системой. Его наличие позволяет ускорять поиск драйверов для установленных устройств, а в дальнейшем – и для их обновления. Другими словами – без индекса нельзя, его создание и дальнейшие обновления критическим образом сказываются на скорости и эффективности работы нашего приложения.
Герои Silicon Valley работают над оптимизацией собственных алгоритмов
Как строится пользовательский индекс драйверов
Для каждого устройства в системе есть свой уникальный номер (DevID).
Он отображается как в установках Windows, так и в программе DriverPack Solution. Уникальный для каждого устройства идентификатор (однозначно характеризующий каждое устройство), используется программой для автоматического «подбора» драйвера к нему.
База данных в программе содержит ID всех устройств, самостоятельно отслеживает версии драйверов для них, сопоставляет их версии и актуальность. В случае наличия в базе более новой версии, программа автоматически предлагает установить для устройства новый драйвер. Можно найти драйвер для конкретного устройства и самостоятельно в интернете, выбрав соответствующий режим поиска драйвера.
Для эффективной работы программы необходимы архивы драйверов (в формате "7z"), а для быстрого поиска по ним, требуется проиндексировать файлы, содержащиеся внутри.
Кроме уже содержащихся (довольно обширных) в программе архивов драйверов, DriverPack Solution предоставляет возможность создания пользовательских драйверпаков. Это актуально как при наличии нестандартного оборудования, так и «привязанности» операционной системы пользователя к некоторым типам (возможно устаревших) драйверов.
Новые драйвера после их разархивации «разбросаны» по папкам, которые содержат массу файлов, на первый взгляд, совершенно «ненужных» пользователю.
Для того, чтобы выбрать «нужные» файлы, требуется в распакованных файлах найти один с расширением *.inf.
Именно он содержит (в секции [SourceDisksFiles]) перечень необходимых файлов, по которому и требуется скопировать список файлов в предварительно созданную пользователем папку.
Примечание: если среди распакованных файлов нет .inf-файла, то автоматическое создание пакета драйверов невозможно. Настоятельно не рекомендуется удалять файлы с расширением *.САТ – сведения о цифровой подписи.
Как было раньше
До 2010 года, пока версий Windows было чуть меньше, нами использовался следующий метод создания индекса к сборке драйверов.
Создается папка D (сокр. от «Drivers»), а драйверы помещаются в любую подпапку внутри директории D.
Имя подпапки (поддиректории) может быть любым, однако рекомендуется использовать максимально короткие имена. Стоит избегать длинных путей к файлам – это может привести к ошибкам и помешать установке.
При создании структуры папок пакета драйверов следует придерживаться определенных общепринятых правил именования. Обязательно должны использоваться только английские названия папок.
В созданных папках драйверы разделяются по производителям, тем самым образуя подпапки.
Названия производителей также рекомендуется максимально сокращать. Например: «NVidia» – «N», «ATi» – «A» и т. д. Внутри папки с именем производителя драйверы располагаются в папках 1-9, при необходимости число папок может быть увеличено. После создания необходимой структуры папок поместите ваши драйверы в соответствующие подпапки (примечание: распакованные файлы, .inf-файлы, но не архивы или программы установки).
Название папки | Английское название | Пояснение |
A | Additions | Дополнения |
B | Broadband | Широкополосные сетевые устройства (*DSL-модемы и им подобные) |
C | Chipset | Наборы системной логики (чипсеты) |
CPU | Central processor unit | Центральный процессор (необходим для AMD K8) |
D | Dial-Up | Модемы |
G | Graphics | Видеоадаптеры (Графические карты) |
L | LAN | Сетевые адаптеры |
M | Mass Storage | Контроллеры жестких дисков |
P | Printers | Принтеры |
S | Sound | Звуковые адаптеры |
VMWare | VMWare | Драйверы для виртуальной машины VMWare |
W | WLAN | Беспроводные адаптеры |
U | USB | USB-устройства (флешки, фотокамеры) |
Y | Misc | Разное (Все что не попало в другие разделы) |
Y | Monitor | Мониторы |
Z | Hid | Устройства ввода (Интелектуальные мыши, клавиатуры тачпады и т.п.) |
Процесс создания (пользовательских) пакетов драйверов
После создания структуры папок с новыми драйверами требуется заархивировать созданную папку (в примере – это папка «D») в соответствии с требованиями программы к архиву.
- Имя архива: «DP_НазваниеПакетаДрайверов_ x86-32_ВерсияПакетаДрайверов.7z»
- Требования: имя архива не должно содержать пробелов. Например, название пакета драйверов версии 9.06 для контроллеров жестких дисков должно быть таким: «DP_MassStorage_x86-32_906.7z.»
- Формат архива: 7z
- Уровень сжатия: «Ultra» (для обеспечения максимальной компрессии, при желании вы можете указать меньший уровень сжатия).
- Метод сжатия: «LZMA» (значение установлено по умолчанию, изменять его не рекомендуется).
- Размер словаря: 32 Mb
Последнее установлено по умолчанию. Можно увеличить или уменьшить значение этого параметра. Увеличение данного параметра позволяет достичь большей компрессии, но требует больше времени для создания архива.
Индексные файлы хранятся в *.txt — формате, и находятся папке «Indexes» а не в «dev_db», как было ранее.
Структуру индексных файлов целесообразно рассмотреть на примере двух драйверов.
Содержимое индексного файла для 1-го:
– «PCI\VEN_8086&DEV_24D5&SUBSYS_680316F3 Audio_w7x64_912.2\ Audio_w7x64_912.2\3\1\Alcwdm18.inf Realtek.NTamd64 06/19/2009,6.0.1.6305 Realtek AC'97 Audio»
Содержимое индексного файла для 2-го:
– «HDAUDIO\FUNC_01&VEN_10DE&DEV_8067 Audio_w7x64_912.2\ Audio_w7x64_912.2\11\1\nvhda.inf VIDIA.NTamd64 11/11/2009,1.00.00.63 NVIDIA High Definition Audio»
Более развернуто объяснение структуры приведено в таблице:
Элементы структуры | Драйвер 1 | Драйвер 2 |
Device ID (идентификатор устройства) | PCI\VEN_8086&DEV_24D5&SUBSYS_680316F3 | HDAUDIO\FUNC_01&VEN_10DE&DEV_8067 |
Путь хранения драйвера в архиве | Audio_w7x64_912.2\Audio_w7x64_912.2\3\1\ | Audio_w7x64_912.2\Audio_w7x64_912.2\11\1\ |
Название inf-файла | Alcwdm18.inf | nvhda.inf |
Тип | Realtek.NTamd64 | NVIDIA.NTamd64 |
Дата выпуска и версия | 06/19/2009,6.0.1.6305 | 11/11/2009,1.00.00.63 |
Название устройства | Realtek AC'97 Audio | NVIDIA High Definition Audio |
Текущие реалии
Сегодня жесткой привязки к структуре индекса нет, что называется, «свободный стиль».
Главное – это использовать маркеры операционных систем. Дополнительно есть маркеры для, практически, всех производителей ноутбуков.
При этом расположение и название папок и подпапок перестало иметь значение, единственное требование – наличие минимально одного маркера системы.
Фактически же маркер – конкретное название папки. Оно видно в названии одного из подкаталогов драйвер-пака: DRP\Drivers\DP_Chipset_14101.7z\Intel\WinAll\Chipset\9.4.0.1007_HECI\
В данном случае «WinAll» значит «все версии Windows».
Версия Windows = маркер (имя подпапки), характеризующий, что драйвер который находится внутри папки-маркера подходит для указанной ОС.
- XP x64 =«5x64»;
- XP x86 =«5x86»;
- Vista x64 =«6x64|NTx64|AllNT|67x64»;
- Vista x86 =«6x86|NTx86|AllNT|67x86»;
- Windows 7 x64 =«7x64|NTx64|AllNT|67x64|78x64|781x64|7819x64»;
- Windows 7 x86 =«7x86|NTx86|AllNT|67x86|78x86|781x86|7819x86»;
- Windows 8 x64 =«8x64|NTx64|AllNT|78x64|All8x64»;
- Windows 8 x86 =«8x86|NTx86|AllNT|78x86|All8x86»;
- Windows 8.1 x64 =«81x64|NTx64|AllNT|781x64|7819x86|All8x64»;
- Windows 8.1 x86 =«81x86|NTx86|AllNT|781x86|7819x86|All8x86»;
- Windows 9 x64 =«9x64|NTx64|AllNT|7819x64|All8x64|81x64»;
- Windows 9 x86 =«9x86|NTx86|AllNT|7819x86|All8x86|81x86»;
- Windows 10 x64 =«10x64|NTx64|AllNT|78110x64|All8x64»;
- Windows 10 x86 =«10x86|NTx86|AllNT|78110x86|All8x86»;
- Все x64 =«Allx64»;
- Все x86 =«Allx86»;
- Все XP =«AllXP»;
- Все Vista =«All6»;
- Все Windows 7 =«All7»;
- Все Windows 8 =«All8»;
- Все Windows 8.1 =«All81»;
- Все Windows 9 =«All9»;
- Все Windows 10 =«All10»;
- Любые Windows =«WinAll»;
Маркеры ноутбуков
Маркер-папка с названием производителя ноутбука = слово, используемое самим производителем для идентификации его ноутбуков
- Acer_nb = acer / emachines / packard*bell / gateway / aspire
- Apple_nb = apple
- Asus_nb = asus
- Dell_nb = dell / alienware / arima / jetway / gericom
- Fujitsu_nb = fujitsu / siemens
- Gigabyte_nb = gigabyte
- HP_nb = hp / compaq
- Lenovo_nb = lenovo / compal / ibm
- LG_nb = lg
- MSI_nb = msi / micro-star
- NEC_nb = nec
- Panasonic_nb = panasonic / matsushita
- Samsung_nb = samsung
- Sony_nb = sony / vaio
- Toshiba_nb = toshiba
- OEM_nb = другие вендоры (benq / clevo / depo / durabook / ecs / elitegroup / eurocom / getac / intel / iru / k-systems / medion / mitac / mtc / nokia / pegatron / prolink / quanta / sager / shuttle / twinhead / rover / roverbook / viewbook / viewsonic / vizio / wistron и т.д.)
Текущий индекс
Если при скачивании с нашего сайта обновленных драйвер-паков их имена файлов совпадают (например, старый и новый файл имеет имя «DP_Chipset_14112.7z»), можно просто заменить старые файлы новыми.
При наличии такого же файла, но с меньшим номером, его можно удалить: скачали «DP_Chipset_14112.7z», но в папке есть «DP_Chipset_14111.7z» — файл с меньшим номером версии «DP_Chipset_14111.7z» можно удалить.
Индексируем новые драйвер-паки (создаем списки поддерживаемых устройств).
Если старые индексы удалены, то при запуске DRP, программа автоматически попросит вас произвести индексацию новых драйвер-паков — например программа для нового драйвер-пака «DP_Chipset_14112.7z» создает файлы-индекса «DP_Chipset_14112_xxx.xxx» в соответствующей папке в «X:\DRP\Indexes\».
Можно также удалить и старые индексы.
В папке «Indexes» необходимо удалить все файлы старого драйвер-пака.
Имени файла индекса соответствуют имя драйвер-пака и найти его легко. Например, вы скачали драйвер-пак «DP_Chipset_14112.7z» а у вас был «DP_Chipset_14111.7z», соответственно удаляем все файлы-индексы «DP_Chipset_14111_xxx.xxx», если же и скаченный и старый драйвер-пак имеют одинаковое имя например «DP_Chipset_14112.7z», то индексы «DP_Chipset_14112_xxx.xxx» также нужно удалить т.к. список поддерживаемых устройств в новой версии драйвер-пака может отличаться.
Если вам лень выискивать нужный для удаления индекс — можно удалить все папку «Indexes» и тогда программа будет создавать индексы для всех драйвер-паков, а не только для нового, что займет больше времени, но результат будет идентичным.
Надеемся, что данное руководство по созданию индекса драйверов будет полезно не только разработчикам DriverPack Solution.
Читайте также: