А этот ваш Windows так умеет?
Начнем по порядку. После предыдущего поста, был реализован мини-драйвер для загрузчика FreeLoader, позволяющий в read-only режиме читать файлы с раздела BTRFS. Здесь меня поджидала первая проблема — BTRFS это регистрозависимая файловая система. Здесь для поиска inode структуры (эта структура содержит базовую информацию о файле) в директории используется хеш имени файла, это позволяет ходить по путям без вытаскивания всех файлов, содержащихся в директории.
Однако, в Windows мире такая вещь как регистр имени файла мало кого волнует, поэтому пути к драйверам, требующимся для загрузки ОС могут быть записаны в реестре в совершенно любом регистре.
В данный момент эта проблема решена старыми добрыми костылями — при запросе на поиск файла, System32 и SYSTEM32 заменяются на system32, то же самое с папкой drivers. Пока я думаю как можно было бы это сделать грамотно. Скорее всего буду каждый раз загружать полный список файлов в директории и делать регистронезависимый поиск — потери скорости на загрузчике особо видны не будут.
Загрузчик читает файлы, костыли закостылены — едем дальше.
Я разрабатывал код загрузчика в виртуальной машине Bochs, поскольку в ней такие вещи делать удобнее всего. Но она (как оказалось) имеет проблемы с запуском ReactOS, поэтому пришлось пересесть на привычный VirtualBox.
И тут меня ждала очередная засада — почему-то не работал загрузочный сектор. Как выяснилось, в реализации прерывания INT 13h AH=42h (расширенное чтение с диска) есть какие-то проблемы, из-за которых эта функция не может читать более 8 секторов за раз.
И вот, наконец, первое сообщение об ошибке (это даже не BSOD!)
Исключение со STATUS_ACCESS_VIOLATION приходило из подсистемы WinSxS, которая в основном взята из Wine. Пару дней пришлось потратить на причину возникновения, поскольку через WinSxS проходит загрузка всех библиотек, а их при запуске много. В конце концов, выяснилось что проблема была не в WinSxS (фух), а в системном вызове NtQueryDirectoryFile.
WinSxS часто использует эту функцию для поиска манифестов по маске (делая запросы типа таких: "*_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.*.*_*_*.manifest"), а в драйвере WinBtrfs закрался баг, связанный с обработкой масок, начинающихся на звездочку. Совсем простенький пулл-реквест можно посмотреть здесь.
Удивительно, но этого было достаточно для того, чтобы пройти установку и загрузиться в рабочий стол
Возможно, первая в мире загрузка с драйвера WinBtrfs. Первая реализация моего фикса тоже имела ошибки, из-за чего кое-где поехала графика и не загружались картинки.
Собственно, система загружается, и даже работает (хотя стабильность не такая как в последнем релизе 0.4.9).
Но проблем ещё полно:
- Нет поддержки файла подкачки. Вообще говоря, на linux swap файлы на btrfs дисках тоже не поддерживаются, а патч висит уже несколько лет. Но WinBtrfs таки их поддерживает. У нас же несколько другая реализация менеджера памяти, чем в Windows, которая требует ещё одного системного вызова, отсутствующего пока в WinBtrfs.
- Ошибки записи и переполнения памяти. Мне удалось зафиксировать парочку таких, например при установке клиента Git. Будем разбираться, где течет память
- BSODы при выключении и перезагрузке. Патч уже ждет одобрения
До конца GSoC осталось уже совсем чуть-чуть, в планах дальнейшее исправление багов, и решение проблемы с файлом подкачки (но это уже после окончания программы).
Ну а желающие поддержать разработку данной фичи, могут присоединиться к тестированию и разработке драйвера WinBtrfs.
Комментарии (58)
rogoz
01.08.2018 17:51NTFS тоже регистрозависимая файловая система. Возможно стоит сделать как сделано в Windows (я не знаю детали, мб у вас уже так сделано, но судя по тексту нет), а не свои костыли. Полагаю в будущем это избавит от других проблем.
khim
02.08.2018 02:16NTFS тоже регистрозависимая файловая система.
Нет. может использовать POSIX-семантику (см. флаг FILE_FLAG_POSIX_SEMANTICS), да — но это опционально. Чтобы обеспечить регистронезависимость (а это не так-то просто, вспомните хотя бы I/I и ?/i у турков) в NTFS — есть таблицы и куча флагов.
Ничего подобного никто в BTRFS вкрутить не даст.GadPetrovich
02.08.2018 14:55+1NTFS условно регистронезависимая ФС, т.е. имена файлов хранятся с учетом регистра, а вот поиск ведется с учетом файла $UpCase, в котором хранятся эквиваленты символов в верхнем регистре для всего Unicode. Более того, регистрозависимость можно включить для требуемых каталогов командой:
fsutil file setCaseSensitiveInfo
pavelpromin
01.08.2018 19:03+1BTRFS и в убунту то ненадежна, а уж про ReactOS и подумать боюсь
Jeditobe
01.08.2018 19:25В ReactOS будет совсем не тот драйвер, что в Ubuntu. Так что нестабильность Ubuntu тут не при чем.
pavelpromin
01.08.2018 19:38"Нет, это был не я. Это был какой-то дурак. Я другой дурак" (Скотт Пилигрим)
В том плане, что хотя у убунта-бэйзет дистрибутивов большая аудитория, драйвера ФС все таки работают нестабильно. А к реактосу недоверия в плане стабильности ещё больше (может необъективно в данном случае, но все же).Jeditobe
01.08.2018 19:49+1Стабильность работы FS определяется в первую очередь конкретным драйвером и его версией для этой FS. То, что BTRFS была нестабильна в Ubuntu, не значит, что можно автоматически заявлять, что будет глючить и под Windows. А драйвер WinBTRFS разрабатывался специально для Windows, а уже потом его решили добавить в ReactOS.
amarao
02.08.2018 13:49С btrfs проблемы уровня дизайна (одно «лживое df» чего стоит). Бубунта никакого отношения к btrfs не имеет, потому что драйвер-то в апстримовом ядре.
GamePad64
02.08.2018 20:41А как по-вашему сделать "нелживые df" в copy-on-write ФС?
amarao
02.08.2018 21:04Иметь точное представление о том, сколько блоков (снизу там всё равно блоки!) выделено, а сколько занято.
Я говорю про ситуацию, когда мы сделали cow, и вдруг видим место, которое будет отличаться от того момента, когда мы в файл запишем. Я говорю про цифру реально свободных блоков прямо сейчас. Утрируя — сколько можно на диск записать в новый файл. Или дописать в существующий.khim
02.08.2018 23:05-1Иметь точное представление о том, сколько блоков (снизу там всё равно блоки!) выделено, а сколько занято.
Прекрасно. Имеем мы такое представление. Что дальше?
Утрируя — сколько можно на диск записать в новый файл.
1 килобайт.
Или дописать в существующий.
100 гигабайт, если правильно выбрать файлы, в которых блоки частично, но не полностью, заняты.
Какую цифру должен выдаватьdf?
—Я говорю про ситуацию, когда мы сделали cow, и вдруг видим место, которое будет отличаться от того момента, когда мы в файл запишем.
Угу. Вот только в любой файловрй системе, в которой бываетinline data(btrfs,ext4,ntfsи так далее) такого числа нет.
Ибо количество данных, которые вы можете записать будет зависеть от того что и куда вы будете записывать.
Да, вbtrfsэто заметнее, чем вext4, но и там и там наличие на диске определённого количества места (скажем 1GB) не обозначает, что вы сможете туда столько записать. Можно настроить алгоритм оценки свободного месте так, чтобы он был более или менее консервативным, но сделать «честный»dfнельзя.
—
Собственно вот как раз пользователи Windows от отсуствии «честного»dfникак не страдают — потому что основная система на NT/XP/etc именно так всегда и была устроена.
А пользователи Linux — да, у них до недавнего времени былаext3(а кое-где иext2), гдеdfмог быть «честным».
Но… всё течёт, всё изменяется. Вext4«честный»dfтоже невозможен, так что, я думаю, со временем пользователи Linux тоже привыкнут к тому, чтоdf— это только оценка…amarao
02.08.2018 23:07Вы цепляетесь к мелким деталям. Ок, вот вам ожидания от df: показания df говорят о том, какого размера новый файл всё ещё можно записать на диск. Плюс-минус инлайны (не существенно).
У меня на btrfs раздел со стимом и меня страшно бесит, что df часто рапортует свободное место, которое меньше, чем разница между размером диска и размером файлов на нём. Сильно меньше. На сотню гигабайт (на терабайтном разделе) меньше. Потом всё нормализуется, но некоторое время — брешет.
И это раздражает.
Newbilius
02.08.2018 14:48-1Автоматически заявлять конечно нельзя. Но можно предполагать, что данный драйвер может быть хуже оттестирован, т.к. над Linux'ом (и под ним) работает несколько большее число людей, чем над/под ReactOS. И раз при тестировании на большей пользовательской базе не удалось отловить все проблемы — удастся ли это сделать меньшей команде, с меньшим числом пользователей и разработчиков? Так что наличие сомнений вполне объяснимо.
mayorovp
02.08.2018 15:10А драйвер WinBTRFS разрабатывался специально для Windows, а уже потом его решили добавить в ReactOS.
sleonov
02.08.2018 19:12-1Начинать стоит с того, чтоб оно в принципе загружалось всегда и везде, а не в конкретной версии virtual-box и на 1 ядре. После этого, видимо, стоит перейти просто к стабильности работы, чтоб оно не падало от каждого чиха. А то вы 20 лет пилите систему, которая и не работает толком. Все эти ваши «а вот теперь с btrfs» — гроша ломанного не стоят, по причине того, что за 20 лет ваш «продукт» не стал даже относительно юзабельным.
Extravert34 Автор
02.08.2018 19:17См. мой ответ mayorovp ниже habr.com/company/reactos/blog/418861/#comment_18952043
EmmGold
01.08.2018 20:16КриптоПро с ключами надо прикрутить и 1С запустить. Уже можно будет на посы в магазины ставить, сетевые магазины могут и подтянутся.
densss2
01.08.2018 20:46+1А Вы, батенька, мечтатель :)
istepan
02.08.2018 06:55Почему же? Правильно рассуждает.
Разработчикам ReacOS можно будет заработать на коммерческой поддержке, как RedHat прям :D
Пилить в первую очередь те вещи, за которые будут платить.
Btrfs вот кому нужна? Пустая трата времени, хотя конечно не мне судить.AllexIn
02.08.2018 08:57Кто будет платить?
istepan
02.08.2018 09:08Компании для которых использование ReactOS будет выгоднее лицензионной Windows.
AllexIn
02.08.2018 09:09За что будет платить?
istepan
02.08.2018 09:15За необходимый ему функционал и тех. сопровождение.
AllexIn
02.08.2018 09:22Если в ОС нет необходимого функционала для работы кассы/терминала — в её сторону даже смотреть не будут. Не говоря уж о том, чтобы оплачивать доработку.
Если ОС не может обслуживать штатный админ и требуется тех поддержка — эту ОС никто не будет использовать на кассах и терминалах.Jeditobe
02.08.2018 11:30Здесь была речь не про альфа-версию, а про релиз.
AllexIn
02.08.2018 11:31+1Это понятно.
Я про то, что либо ReactOS сразу будет пригодной для терминалов и не понятно за что платить, либо если она не пригодна — платить никто не будет.Areso
02.08.2018 19:30Промежуточных значений в вашем мире не бывает? Например, есть терминалы, которые работают с Вистой или 7. И только с ними. Есть, которые с XP. И только с Хрюшкой.
Если сделать так, что условно любые виндоус терминалы будут работать, то это будет эпик вин и киллер-фича. Вообще, поддержку оборудование можно добавлять постепенно.AllexIn
02.08.2018 19:45Нет, в моем мире не бывает промежуточных значений. Я не могу понять, кто и зачем будет доплачивать сколь либо значимые суммы команде ReactOS, когда можно тупо купить Windows 2009 POSReady и гарантированно получить работоспособную ОС.
P.S.
Стоит заметить, что уже сейчас ReactOS используется на терминалах. Пожалуй только отсутствие уверенности в стабильности мешает более массовому использованию.
mayorovp
02.08.2018 10:37+1Btrfs вот кому нужна? Пустая трата времени, хотя конечно не мне судить.
Кажется, это первая нормальная ФС с которой ReactOS может загружаться. Не знаю насколько оправдан выбор именно этой ФС, но работа была проделана явно не впустую.
Extravert34 Автор
02.08.2018 19:16Btrfs в первую очередь нужна как ФС с полным набором фичей — ссылки, ACL, аттрибуты и прочее. В FAT этого всего нет
Второй момент — это помогает фиксить баги в менеджере памяти. А недоделанный менеджер памяти это основная штука, которая мешает системе нормально работать
Siemargl
01.08.2018 20:24Проблемная ФС. В линухах уже ее выкидывают (deprecated).
И получается, что в Реакте нет (пока) ни одной нормальной современной ФС.
Хорошо бы что то быстрое типа HPFS/NSS или надежное типа JFS/NTFS. Но нужна хорошая реализация (КО)Extravert34 Автор
01.08.2018 20:28Откуда информация про deprecated?
Я слышал только что её из RHEL выкинулиamarao
02.08.2018 13:52Она не «deprecated», просто на неё были большие надежды (убийца zfs), которые не очень сбываются. Примерно пять лет назад попытка применить btrfs для специфичных нужд продакшена показала, что оно не очень стабильно (mtbf — примерно пол-года), а с тех пор её, конечно, фиксили, но всё меньшими темпами.
Итог:
Btrfs was introduced in Red Hat Enterprise Linux 6 as a Technology Preview, available on AMD64 and Intel 64 architectures. The Btrfs Technology Preview ended as of Red Hat Enterprise Linux 6.6 and will not be updated in the future. Btrfs will be included in future releases of Red Hat Enterprise Linux 6, but will not be supported in any way.
access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/ch-btrfs
Siemargl
01.08.2018 20:53Это разработка Оракла/РХат — они же ее и хоронят. Т.е. энтерпрайз минус
В Сузи еще осталась, но %рынка не тот
isden
02.08.2018 11:41Эх, вот кто бы WinZFS запилил :)
А то только год назад показали что-то вроде демки и все, никаких новостей с тех пор.
An OpenZFS port of code to Windows is not likely in the foreseeable future
punkkk
02.08.2018 14:02Однажды вдохновился проектом, но уже прошло 7 лет, а никаких существенных продвижек, кроме дизайна сайта, не наблюдается. :(
oller
02.08.2018 19:05Я не понимаю реально смысла в BRTFS, разве не нашлось чего-то уже готового и надежного? ZFS? Ext4?
Extravert34 Автор
02.08.2018 19:09Дравйвер BTRFS для Windows на данный момент самый готовый и надежный среди других открытых. Надежнее только fastfat от Microsoft, который они недавно выложили. Но у нас менеджер памяти пока не до конца доделан, чтобы с ним работать
isden
02.08.2018 21:10> fastfat
А это разве не «сферический драйвер в вакууме»?
В btrfs же есть всякие фишки вроде снепшотов, компрессии, checksums и тп. На мой личный взгляд, интереснее только ZFS.
computerix
02.08.2018 19:05Очень интересный проект. А что там с поддержкой USB? Или я что-то пропустил и уже запилили.
an11n1
02.08.2018 19:07А этот ваш Windows так умеет?
Для пользователей Windows в этом нет никакой нужды, как и, в скором времени, для пользователей всех остальных ОС.
Sabubu
> а в драйвере WinBtrfs закрался баг, связанный с обработкой масок, начинающихся на звездочку
А почему поиском по маске занимается драйвер? Разве это не одинаковая для всех файловых систем функция (перебрать файлы и отобрать подпадающие под маску)? Или это дает возможности каких-то оптимизаций?
Extravert34 Автор
Думаю да, дело в возможности оптимизации.
В принципе, все запросы к директориям делаются через один и тот же IRP, обычно их обрабатывает один метод в драйвере
docs.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj-directory-control
Jeditobe
Предполагаю, что речь идет о возможности работы на самом раннем этапе загрузки системы. Могу ошибаться.