А я вчера пожарку на тыртырфс перевел. Очень доволен. Осталось разобраться с winbtrfs в десятке, и перевести хомяк в тыртырфс (сегодня пытался, но конвертер выдал ошибку).

А какие технические основания для изменения?

Хорошая новость. Главное, возможность установки на FAT не выпиливать.

А Windows XP тоже так умеет?

Хорошая новость, вносите квазарчика

до момента пока не будет доработан драйвер для NTFS

Шаг назад, ради плагиата?

возможностей FAT уже начинает не хватать

Интересно, почему выбор замены пал на btrfs.

Пожарка - это Manjaro?

Интересно, почему выбор замены пал на btrfs.

Я тут мимокрокодил, но ТС объяснил, почему:

В ReactOS обеспечена возможность загрузки с Btrfs (комментарий)

Вообще, какая разница что за файловая система у админа локалхоста? Примерно такая же, как разница в DE.

А Windows XP тоже так умеет?

Работать с Btrfs - да, если драйвер поставить.
Грузиться с нее - нет.

Там всё так плохо?

По мере добавления функционала в систему

Предлагаю в добавок к функционалу добавить в систему тензор, матрицу и парочку интегралов.

Да.

Да хз, просто попробовать захотел, тем более что можно вернуться к ext4. В федоре тыртыр так и не завелся, несмотря на то, что модуль был добавлен и дракутом собран, а пожарка без особых проблем завелась и даже лучший результат показала, чем на ext4.

Что есть «пожарка»?

Ыыыыы. Учитывая, что btrfs из своих продуктов уже выпиливают создатели, то в ректале ему самое мето, ога. Хуже - не будет. Некуда :)

У тебя unsigned int underflow.

Manjaro.

Ура! Вендекапец близок.

Разница между FAT32 и NTFS есть. Как и разница между линуксовыми ФС. Некоторые хуже, некоторые лучше. Пробовал я как-то XFS. Разницу с EXT4 не заметил, а раздел с XFS еще и уменьшать нельзя.

тыртыр дракутом и пожарка - это быдлосленг.

Приведи пример не быдлосленга

В ReactOS обеспечена возможность загрузки с Btrfs (комментарий)

Пнятненько, значит всё, что не нравится анониму - быдлосленг.

Потому, что есть хороший опенсорсный драйвер под винду и потому что BTRFS многократно лучше, чем FAT

Так себе объяснение.

Для меня лично главная фишка btrfs - снапшоты. Ради них отказался от ext4, и они действительно несколько раз уже выручали. Ну и фоновая компрессия тоже пару раз полезной оказалась.

Итак я чуток разгреб дела и можно начать препарацию очередной порции, того, что по недоразумению назвали ОС :) Когда я первый раз читал рпус в виде новости меня аж по глазам резануло:

Однако, теперь был создан загрузочный сектор для раздела с BTRFS

Ви таки знаете, это пи-ц. Я думал, разрабы реакта и так пробили дно, но теперь они берут новый рекорд. Я поясню, потому как недоучки или неправильно выразились, ибо опять все делают в своем репертуаре, т.е. через задницу. Итак. НЕ БЫВАЕТ ЗАГРУЗОЧНОГО СЕКТОРА ДЛЯ ФАЙЛОВОЙ СИСТЕМЫ! Ибо ОС грузятся по следующему алгоритму. BootSector - это первый физический сектор (или если хотите адрес) на носителе. Ну или разделе (mbr или там gpd - не важно). Все что там находится -просто и тупо передает управление бутлоадеру. Ответте мне на вопрос - каким боком тут файловая система, если еще даже ос - не загружена? Это примерно как сказать, что яйцо снесло курицу. Мало того. На PC, единственное требование к загрузочному сектору - это наличие в нем в последних байтах значений 0x55 и 0xAA. Что тут писать ? Эта вся ДичЪ будет выглядеть примерно вот так: section .text use16 org 0x7c00 start: mov ax, cs mov ds,ax mov si, massage cld mov ah, 0x0e mov bh, 0x00 i_loop: lodsb test al,al jz i_loop_exit int 0x10 jmp i_loop i_loop_exit: jmp $ message: db 'kUkU',0 finish: times 0x1fe-finish+start db 0 db 0x55, 0xaa

Собственно все что надо разрабам ректала, так это вместо вывода kUkU - выполнить переход на свой загрузчик системы, в котором загрузить драйвер ос. ЭТО ДЕЛАЕТСЯ НЕ В КОДЕ ЗАГРУЗОЧНОГО СЕКТОРА, ДАУНЫ! Потому как у вас, как я правильно понял заявлена поддержка куево кукуевой тонны фс.

Перестаньнте уже заниматься всякой фигней, посмотрите как делают такие вещи, а потом уже делайте громкие заявления про ОС и все такое, ибо у меня складывается офигенное впечатление, что вы, идиоты, взялись писать систему, вообще нифига не зная банальных основ того, как это все работает. Перестаньте позориться.

Ура! Вендекапец близок.

Угу. Скорее вендже настанет капец, прежде чем выйдет версия 1.0 этого барахла.

Тебя нормальный человек не поймет. Если тебе это вовсе не важно, можешь продолжать разговаривать на своей, невероятно крутой, абракадабре.

NTFS - закрытая файловая система (чёрный ящик) и сделать драйвер для неё не так просто, но работы ведутся.

Вы там в начале 2000-х еще барахтаетесь?

Вы там в начале 2000-х еще барахтаетесь?

Зато теперь все знают, где находится, часто упоминаемая на лор-е криокамера. Это - место разработки реактос :) Вот где ее разрабатывают - там и криокамера.

Надеюсь, будет полезно обоим проектам и однажды в ReactOS всё-таки появится поддержка прав доступа к файлам.

однажды в ReactOS всё-таки появится поддержка прав доступа к файлам

А ты - оптимист....

однажды в ReactOS всё-таки появится поддержка прав доступа к файлам.

Ко всем файлам без всякого ограничения.

Заходят бар бесконечное количество математиков...

Это и так есть, а теперь-то оно может грузиться с драйвера, у которого в Feature List написано:

* Getting and setting of Access Control Lists (ACLs), using the xattr security.NTACL

Удачи проекту.

Вот оно что. Одалист всё обсирает. Абсолютно всё. А тут «удачи»... Удивил.

П.С. Но одалист всё равно говно.

И половина сразу же выходит. Сколько их осталось?

посмотрите как делают такие вещи

У меня для тебя плохие новости:

В ReactOS обеспечена возможность загрузки с Btrfs (комментарий)

Когда делали поддержку NTFS про длрайвер ntfs-3g знали, его изучали, но он мало чем помог.

То есть они не могут изучать, смотреть и т.п. Жаль конечно.

Специалисту обойти права доступа не проблема. А неприятностей доставить права доступа могут, скопировал на флешку, принес на другой комп, а система тебе фугу кажет - не ты это :) , а нужно срочно, а время идёт...

Права доступа - это фитча, не более.

Надоел Эзопов язык, чо-то лень сёдня. Поэтому..

Кто платит этим придуркам?

Видел этот тред на двух страницах.

Шаг назад, ради плагиата?

Пока BTRFS сжирает данные вместе со свободным пространством, NTFS просто работает.

Правильно-ли я понимаю, что загрузочный сектор диска - это ещё не файловая система, но в нём находится код позволяющий компьютеру читать файл, который находится на файловой системе, в котором необходимые команды для загрузки системы?

Так LVM-2 же умеет в снапшоты c XFS (и без кажется тоже).

Ну все, все проблемы решены.

https://habr.com/company/reactos/blog/416367/

Поскольку FreeLdr повторяет принцип работы загрузчика ntldr от MS, он состоит из двух частей — загрузочного сектора в начале раздела, куда передает управление MBR диска, и основной части, которая переводит процессор в защищенный режим, загружает ядро ntoskrnl.exe в память, и делает ещё кучу всего.

https://habrastorage.org/webt/cl/go/i1/clgoi1um3vitkoe9crfvakqkzeq.png
(так выглядит процесс загрузки ReactOS)

Таким образом, для поддержки новой файловой системы, нужно написать загрузочную запись раздела (VBR), задача которой найти в корневой директории диска исполняемый файл основной части загрузчика (у нас он называется freeldr.sys), загрузить его в память и передать туда управление. Но это ещё не всё, в самом freeldr.sys нужен практически полноценный read-only драйвер файловой системы, для того чтобы считывать конфигурационные файлы, ядро, кусты реестра и т.д.

Вначале нужно было разобраться с самой файловой системой BTRFS. До этого самыми сложными вещами, что я ковырял были fat32 и ext2, так что на изучение “комбайна” BTRFS мне потребовалось немало времени. Документация на wiki.kernel.org помогает разобраться, но для полного понимания её было недостаточно — приходилось ходить в исходники grub, u-boot и других загрузчиков. Очень полезной для изучения строения файловой системы оказалась утилита на python, которую я написал для вывода структур файловой системы в консоль. С помощью нее я и написал первый прототип загрузочного сектора, который вытаскивает загрузчик из бинарного файла с образом диска с файловой системой BTRFS.

https://habrastorage.org/webt/wm/w9/om/wmw9ommue1ojm4ys1wnbenakzvw.png
(на картинке видны элементы корневой директории)

Теперь пришло время настоящего загрузочного сектора. Осложняется его написание тем, что тут мы работаем в реальном режиме процессора со всеми вытекающими последствиями (~1мб памяти, сегментная адресация и работа с диском через прерывания BIOS). Раздолье для любителей олдскула типа меня :)

В структурах BTRFS почти все поля имеют 64-битный размер, что весьма “раздуло” код, поскольку пришлось активно использовать 32-битные x86 инструкции. Частенько приходится использовать конструкции типа:

mov si, SOME_OFFSET
lea si, [esi+ecx*8] 
lea si, [esi+ecx*8]
lea si, [esi+ecx*8] // one element is 24 bytes long

Самой трудоёмкой оказалось написание процедуры обхода b-дерева, на её отладку ушло больше всего времени. И после нескольких бессонных ночей, мне таки удалось получить заветное сообщение об ошибке из второго этапа загрузки:

https://habrastorage.org/webt/xw/ou/zr/xwouzrpnw0_wbttpcghv8j7q6am.png
freeldr.sys получилось успешно загрузить в память, и даже не понадобилось использовать магию вроде Unreal Mode. 640кб хватит всем!

Постесняюсь полюбопытствовать. А вендовые права доступа \ ACL оно ест?

Примерно. Существуют разные системы разбивки диска и разные загрузчики.

в мсдос разбивке загрузчик из загрузочного нулевого сектора загружал сам груб из дырки между нулевым сектором и началом разбивки, который в свою очередь уже поддерживал чтение из файловой системы. В gpt этой дырки уже нет, поэтому создают специальную партицию и самый первый загрузчик читает основной загрузчик оттуда. А тот уже читает из файловой системы.

А в uefi и вовсе сразу в биос прошили драйвер fat32 и читают сразу из файловой системы.