Глава 6. Файловая система

Для поддержки файловой системы Linux, запущенной поверх Windows, подсистема Windows для Linux приходится транслировать все выполняемые в файловой системе Linux операции пользователя в операции ядра NT. Более того, пользователи должны иметь возможность доступа к файлам Windows из определённого дистрибутива Linux, запущенного поверх WSL.

Для обеспечения этого, WSL обладает компонентой VFS, встроенной в lxcore.sys, которая моделируется для эмуляции операционной системы VFS (Virtual File System) Linux. Основная роль VFS в операционной системе Linux состоит в предоставлении уровня абстракции для управления всеми теми файловыми системами, которые монтируются в некий момент в Linux. Эта абстракция снабжает общие операции (такие как open, read, chmod, stat) и реализуется безотносительно от тех лежащих в основе файловых систем, которые могут сосуществовать. Вот некоторые из этих файловых систем:

Давайте рассмотрим каждую из них по отдельности.

Это самая первая файловая система в WSL, которая применяется для хранения всех файловых систем Linux и вашего каталога home и обладает практически парными свойствами по сравнению с Virtual File System (VFS) Linux. Технически, все файлы находятся в Windows и WSL предоставляет полный доступ к этим файлам эмулируя поведеие самой Linux для внутренних файловых систем Linux, например, следующие каталоги, которые добавляются во все дистрибутивы Linux:

Однако основной целью этой файловой системы является не возможность взаимодействия, а в основном предоставлении практики самой Linux своему пользователю, с которой он знаком, такой как каталоги /home или /root. При этом следует отметить, что если новый файл добавляется со стороны самой Windows, он не обладает правильными расширенными атрибутами, которые понимаются volfs, и они просто игнорируются, и такие файлы становятся непригодными для дистрибутива Linux в подсистеме Windows для Linux.

Давайте рассмотрим некий пример создания файла из Windows в этой файловой системе чтобы лучше разобраться. В этом первом подходе мы попытаемся создать некий файл в моём каталоге /home/prateek в папке %LocalAppData%\ из моей машины Windows 10, где размещаются все файлы пакетов для моего дистрибутива Linux Ubuntu 18.04.

Обратите, пожалуйста, внимание, что этот первый подход не рекомендуемый способ добавления файлов в ваш дистрибутив Linux из WSL и может приводить к разрушению файла и неполадкам. Советуем не прикасаться к этой папке со стороны Windows:

$rootFS = "Packages\<package name>\LocalState\rootfs\home\<username>"
$param1 = @{
            ItemType = 'File'
            Path = "$env:LOCALAPPDATA\$rootFS\file1.txt"
}
New-Item @param1 -Verbose
		

Если мы выполним предыдущую команду из консоли PowerShell на стороне Windows, мы обнаружим соответствующий файл file1.txt, созданный из консоли PowerShell. То же самое можно проверить из папки %LocalAppData%. Однако, если вы пристальнее взгляните на Рисунок 6-1, file1.txt пропущен в дистрибутиве Ubuntu, запущенном в WSL.

С другой стороны, когда мы создаём файл с названием “file1.txt”, применяя второй подход, который заключается в пути UNC \\wsl$\, как это показано на Рисунок 6-2, при помощи нашего следующего кода примера, он создаёт не только сам файл, но этот файл также теперь доступен и в нашей подсистеме Windows для Linux, в отличии от нашего первого подхода. Ещё раз подчеркнём, что рекомендуется применять именно этот второй подход для создания файлов WSL из Windows, и это не самый лучший подход для создания и изменения файлов из пакетов Linux, размещаемых в папке %LocalAppData%:

$param2 = @{
            ItemType = 'File'
            Path = \\wsl$\Ubuntu-18.04\home\prateek\file2.txt
}
New-Item @param2 -Verbose
		

Создание файла при помощи пути \\WSL$\<package>\ работает потому, что сама подсистема Windows для Linux добавляет некоторые расширенные атрибуты при помощи этого метода при создании данного файла и Рисунок 6-3 демонстрирует эти extended attribute (EA), нашлёпанными на “file2.txt”, но пропущенными для “file1.txt”, при их проверке через “fsutil.exe”.

Эта файловая система монтируется автоматически в дистрибутивах Linux для предоставления возможности взаимодействия с Windows с тем, чтобы смонтированные в файловой системе NT являлись доступными из подсистемы Windows для Linux, как это показано на Рисунке 6-4. В настоящее время drvfs поддерживает только New Technology File System (NTFS) и новейшую файловую систему Microsoft Resilient File System (ReFS). Подсистема Windows для Linux автоматически смонтирует фиксированные диски в папке /mnt в качестве:

Когда мы открываем некий файл в drvfs Windows, полномочия файла применяются через списки управления доступом (ACL, access control lists), что означает, что даже когда вы применяете sudo для полномочий root в среде WSL, даже в этом случае это не означает, что вы можете получать доступ ко всем папкам NTFS, поставленным в соответствие через drvfs. Например, если вы пытаетесь выполнить доступ к /mnt/c/Windows полномочий sudo самих по себе не будет достаточно и вам придётся запускать надлежащий экземпляр WSL с повышенными полномочиями.

Всё из tmpfs является временным (temporary) в плане того, что никакие файлы не создаются в вашем постоянном хранилище, например, на жёстком диске. Вместо этого все файлы удерживаются в непостоянном хранилище, например, в виртуальной памяти. Это означает, что если вы размонируете tmpfs, всё хранимое в ней будет утрачено.

Для создания файловой системы tmpfs применяет сочетание памяти (ОЗУ) и основанном на диске пространстве подкачки и, поскольку она применяет ОЗУ, она очень быстрая для считывания и записи данных по сравнению с записью на диск. Как видно на Рисунке 6-5, имеется множество каталогов, которые монтируются при омощи этой файловой системы, например /dev и /run.

procfs и sysfs являются специальными файловыми системами, которые представляют такие сведения о системе как ЦПУ, процессы, драйверы, устройства и конфигурации, которые в основном динамически вырабатываются при их считывании. В фоновом режиме WSL запрашивает эти сведения у ядра Windows NT без какого бы то ни было взаимодействия с NTFS.

procfs является более ранней реализацией, в которой основная часть сведений о системе можно найти в каталоге /proc, как это показано на Рисунке 6-6 и в следующих примерах, в которых мы можем проверять задействованное время работы системы:

> cat /proc/uptime
# и проверяем номер версии ядра Linux:
> cat /proc/version
		

Начиная с версии 2.6 ядра Linux, была реализована новая файловая система с названием sysfs, которая предоставляет сведения в /sys в более структурированном и более простым для поиска образом. /sys может использоваться для получения сведений, таких как установки мощности и значения физических адресов порта Ethernet, как это продемонстрировано на Рисунке 6-7.

Множественный поставщик UNC (MUP, multiple UNC provider) является компонентой режима ядра части исполняемого файла mup.sys, который отвечает за перенаправление доступа к любой удалённой файловой системе на основе UNC в некий ретранслятор сетевой среды (соответствующий поставщик UNC), который способен заполнять такие запросы файловой системы.

В целом, MUP определяет какой поставщик способен обрабатывать некий путь UNC в некой операции на основе имени, и и именно это носит название “prefix resolution” (разрешения префикса). Как показано на Рисунке 6-8, тот порядок, в котором опрашиваются такие поставщики сетевой среды на предмет разрешения префикса, основывается на разделяемой запятой такой записи реестра:

PS > $path = 'HKLM:\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\'
PS > (Get-ItemProperty $path).ProviderOrder -split ','
 	   

Когда запущен некий экземпляр WSL, инициирутся процесс init, который настраивает в WSL сервер 9P и сокет Ubux для взаимодействия, которые далее применяются службой диспетчера LXSS для регистрации соответствующих названий пакета WSL, а сокет Unix для установленного серера 9P для ретранслятора 9P, применяемого MUP.

Итак, когда некий пользователь из Windows предпринимает попытку доступа к пути UNC \\wsl$\<packagename> для файловой системы WSL, далее, под капотом MUP, это работает для разрешения префикса и в конечном итоге используется P9NP (Plan 9 Network Provider, сетевым поставщиком Плана 9) для подключения к некому файловому серверу 9P, запущенному в WSL для допуска файловых операций и возможности взаимодействия между двумя системами.

9P (или Plan 9 File System Protocol, Протокол файловой системы План 9) это сетевой протокол, который применяется для настройки файлового сервера 9 (в WSL) и клиента (в Windows) для установки моста между файловыми системами Windows и Linux и предоставления бесшовной возможности взаимодействия. Существуют различные причины почему применяется этот протокол вместо использования протокола SMB, который уже популярен в операционной системе Windows. Вот некоторые причины:

Прежде чем мы поймём архитектуру файловой системы WSL и способы доступа к файлам из Windows в Linux и наоборот, давайте вначале разберёмся в рабочем процессе установки, который является неким требованием возможности взаимодействия между имеющимися файловыми системами при помощи последующих шагов, причём эти шаги выделены голубыми стрелками с номерами на Рисунке 6-9:

После того, как эта изначальная установка завершена, тогда в доступ к некомы файлу из Windows в запущенную под WSL операционную систему Linux вовлечены такие шаги:

При создании файлов приложения Windows применяют API CreateFile, обладая возможностью передачи флага FILE_FLAG_POSIX_SEMANTICS, который служит некой индикацией того, что в данном пути включена чувствительность к регистру. Вы можете дополнительно ознакомиться с этими API и флагом. Операционная система Windows получила такую возможность начиная с Windows XP, однако она по умолчанию перекрывается через глобальный реестр.

Для поддержки чувствительных к регистру файлов, применяемых запущенными под WSL приложениями Linux, подсистема Windows для Linux имеет иной механизм передачи установок глобального реестра для настройки флага FILE_FLAG_POSIX_SEMANTICS, чтобы предоставить своему пользователю практику чувствительности к регистру, в точности как в Linux, но при этом делает такие файлы также доступными и из приложений Windows.

наша подсистема Windows для Linux применяет иной механизм, который сам по себе передаёт такой ключ регистра, позволяя нам выполнять чувствительные к регистру действия. Именно это позволяет запускаемым в WSL приложениям Linux применять имена файлов, которые отличаются лишь в регистре, причём в точности как они это могут делать в реальном Linux, даже с установленным глобально ключом регистра. Всегда имеется возможность изменить эту настройку чувствительности к регистру, однако давайте не забывать, что это глобальная настройка и её изменение изменит чувствительность к регистру для всех устройств, что может быть вовсе не тем чего вы желаете и может повлечь к нежелательному поведению для приложений или даже сломать некоторые из иных приложений.

Для обхода этой помехи был реализован новый флаг для включения или отключения чувствительности к регистру на уровне некоторого каталога вместо глобальной настройки, причём не зависимо от флага FILE_FLAG_POSIX_SEMANTICS для файлов из этого каталога. Этот новый флаг также существовать в неком каталоге двум файлов с одним и тем же названием, но с различными регистрами букв и при этом продолжать быть доступными из приложений Windows.

Начиная с Windows 10 сборки 17107, мы можем применять fsutil.exe для просмотра и изменения данного флага при помощи такого синтаксиса команд:

> fsutil.exe file queryCaseSensitiveInfo <directory path>
> fsutil.exe file setCaseSensitiveInfo <directory path> <enable\disable>
		

Для включения этого флага чувствительности к регистру при помощи данной fsutil.exe воспользуйтесь следующими шагами:

Начиная со сборки 17692 Windows 10, регулирование чувствительности к регистру обеспечивалась из самой подсистемы Windows для Linux через некий расширенный атрибут system.wsl_case_sensitive на основе установки для каталога. Для просмотра и изменения этого расширенного атрибута мы можем пользоваться командами Ubuntu getfattr и setfattr и вам может потребоваться их установка через

> sudo apt install attr
		

Для включения данного атрибута она устанавливает “1”, а “0” отключает этот атрибут.

Наша подсистема Windows для Linux позволяет нам управлять чувствительностью к регистру для опций монтирования drvfs при помощи раздела [automount] в файле /etc/wsl.conf и по умолчанию такие устройства Windows монтируются в WSL не чувствительными к регистру. Это означает, что когда установлен case=off, тогда всякий вновь создаваемый в смонтированном в “drvfs” каталог будет не чувствительным к регистру.

Давайте попробуем это: когда я проверяю свои смонтированные устройства я вижу по умолчанию drvfs установленными в case=off:

> mount | grep case
		

И когда мы создаём некий новый каталог и проверяем расширенный атрибут system.wsl_case_sensitive при помощи getdattr, как это отображено на Рисунке 6-11, мы наблюдаем, что он установлен в “0”, что подразумевает, что этот каталог не чувствителен к регистру:

> mkdir /mnt/d/newdir

> cd /mnt/d/
> getfattr -n system.wsl_case_sensitive newdir
		

Итак, если мы попробуем создать два файла с одним и тем же названием, но с различиями в регистре, тогда наш первый файл будет перезаписан вторым и будет иметься лишь один файл:

> touch newdir/file.txt
> touch newdir/FILE.txt
> ls newdir/
		

Для включения чувствительности к регистру изнутри WSL мы включаем этот расширенный атрибут в данном каталоге, как в следующем примере:

> touch newdir/FILE.txt
> ls newdir/
		

Теперь, когда мы создаём файл с другим регистром букв, тогда будут созданы два разных файла с одним и тем же названием, но в различных регистрах: “file.txt” и “FILE.txt”, как это демонстрируется на Рисунке 6-12:

> setfattr --name system.wsl_case_sensitive --value 1 newdir
> getfattr -n system.wsl_case_sensitive newdir
		

Подсистема Windows для Linux позволяет нам также устанавливать параметры монтирования в файле /etc/wsl.conf в case=dir, что означает, что все вновь создаваемые каталоги по умолчанию будут обладать включённой чувствительностью к регистру. Это демонстрируется на Рисунке 6-13:

Microsoft со временем делала возможность взаимодействия файловых систем между Windows и Linux всё более и более гладкой и порой трудно понять что это две разные операционные системы, которые обладают высокой интеграцией, а не изолированы, что наводит мосты на разрыве между ними и позволяет пользователям выбирать лучшее из обеих вселенных и пользоваться тем, чо им больше нравится, где им нравится и как им нравится.

Основная роль монтирования файловой системы drvfs в подсистеме Windows для Linux состоит в предоставлении доступа к файлам из вашей Windows 10, поэтому все смонтированные в некой файловой системе NT устройства монтируются и в WSL. Например, устройство C: из NTFS будет доступно в WSL как /mnt/c/ и аналогично D: как /mnt/d/.

Например, как это показано на Рисунке 6-14, мы можем перечислять содержимое своих каталогов при помощи команды ls и значения пути /mnt/d/<path to directory> и это вызаст список всех файлов Windows в нашей подсистеме Windows для Linux.

Дополнительно к этому мы можем также считывать содержимое этих файлов Windows и даже применять свой любимый редактор Linux, например, nano для изменения тех файлов, которые располагаются в файловой системе NT Windows 10, что демонстрирует Рисунок 6-15.

WSL также позволяет применять приложения Windows для доступа к файлам из дистрибутивов Linux. Например, мы можем пользоваться Windows File Explorer (explorer.exe) для открытия текущего рабочего каталога из некой консоли WSL.

Как вы можете видеть в следующем примере, мы способны запустить свой текущий каталог, то есть /home/prateek/ в проводнике в качестве совместно используемого на основе UNC пути \\wsl$\Ubuntu-18.04\home\prateek\ , выделенного на Рисунке 6-16. Здесь я могу перемещать, изменять и выполнять все виды файловых операций, причём все эти изменения будут отображаться обратно в нашем дистрибутиве Linux, запущенном в WSL.

Такие команды, как cp, применяемые для копирования файлов можно применять с монтированиями drvfs для доступа к устройствам NTFS Windows и копировать файлы в Linux, как это демонстрируется на Рисунке 6-17.

Или, как это показано на Рисунке 6-18, использовать mv для перемещения файлов или папок из Windows в подсистему Windows для Linux.

Наилучшая часть состоит в том, что WSL предоставляет нам возможность смешения и установки соответствия команд между операционными системами, ещё дальше наводя мосты над промежутком между Linux и Windows. В нашем следующем, продемонстрированном на Рисунке 6-19 примере, я применяю ipconfig.exe, который относится к исполняемым в Windows для получения IP настроек из Windows в WSL, затем фильтрую получаемый вывод при помощи команды grep, которая является командой Linux, а потом снова сохраняю свой файл с полученным результатом в файловой системе NT Windows с применением параметра монтирования /mnt/ в своей подсистеме Windows для Linux. Я имею в виду, насколько это круто и то, что подобный уровень гибкости, объединяющий лучшее из обеих вселенных трудно найти.

> ipconfig.exe | grep IPv4 > /mnt/d/ipaddress.txt
> cat /mnt/d/ipaddress.txt
		

Поскольку файловые системы подсистемы Windows для Linux теперь высоко интегрированы с Windows File Explorer (explorer.exe), все имеющиеся дистрибутивы Linux теперь доступны по специальному пути UNC \\wsl$\, как это демонстрируется на Рисунке 6-20. Я могу видеть все содержащиеся в них файлы и папки внутри своего Проводника Windows.

Обратите, пожалйста, внимание, что эти пути для индивидуальных пакетов дистрибутивов появляются только когда такой дистрибутив Linux поднят и запущен. Когда определённый дистрибутив Linux не запущен в WSL, он не появится в UNC пути \\wsl$\.

Итак, если вы желаете перейти к своей файловой системе Ubuntu из Windows, просто пройдите к адресной полосе в своём Проводнике и наберите \\wsl$\Ubuntu018.04\, как это продемонстрировано на Рисунке 6-21 а заетм нажмите Enter и это переместит вас в корневой каталог вашей файловой системы Linux.

Этот путь UNC \\wsl$\<disto-name>\ можно применять для изменения файов Linux, располагающихся в вашем дистрибутиве из CMD.exe или PowerShell.exe, причём эти изменения будут отражены в вашем дистрибутиве Linux. Как показано на Рисунке 6-22, если мы создадим один файл из своего приглашения командной строки Windows и один из PowerShell и поместим их оба в мой домашний каталог дистрибутива Linux с применением пути UNC \\wsl$\, а затем когда мы перечислим все элементы из этой папки, мы сможем обнаружить оба этих файла с правильным содержимым на стороне WSL.

Поверх этого вы также можете применять подсистему Windows для Linux чтобы запускать команды при помощи wsl.exe и применять результаты в соединении с такими командами CMD.exe, как findstr или cmdlet PowerShell подобными Select-String для смешения обеих вселенных воедино, как это отражено на Рисунке 6-23 для улучшения эффективности пользователя и привнесения в одно место наилучшего из этих обеих вселенных.

В этой главе мы изучили такие компоненты файловой системы, как VFS, volfs, drvfs, tmpfs, procfs и sysfs, которые совместно с сервером 9P и поставщиком множества UNC (MUP) делают возможной такую файловую систему WSL1; позднее мы взглянули на архитектуру файловой системы WSL2, поскольку WSL2 теперь запускается в облегчённой вспомагательной ВМ с поддержкой ядра, поставляемого с Windows 10. Мы также рассмотрели несколько примеров чтобы разобраться как работает чувствительность к регистру в WSL при поддержке расширенного атрибута и как регулировать и управлять неким каталогом или настраивать его на уровне монтирования drvfs. Наконец, мы завершили эту главу возможностями взаимодействия Windows и Linux, предоставляемыми WSL, которые делают возможным для пользователей запускать исполняемый файлы Windows из Linux, а приложения Linux из Windows, и позволяет продвинутым пользователям запросто смешивать и подгонять наилучшее из обеих вселенных. В своей следующей главе мы изучим построение сетевых среды WSL и то, как заполняются DNS и сетевые интерфейсы на стороне WSL, а также различия между сетевыми средами WSL1 и WSL2.