Как стать автором
Обновить

Комментарии 63

> а в драйвере WinBtrfs закрался баг, связанный с обработкой масок, начинающихся на звездочку

А почему поиском по маске занимается драйвер? Разве это не одинаковая для всех файловых систем функция (перебрать файлы и отобрать подпадающие под маску)? Или это дает возможности каких-то оптимизаций?
Думаю да, дело в возможности оптимизации.
В принципе, все запросы к директориям делаются через один и тот же IRP, обычно их обрабатывает один метод в драйвере
docs.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj-directory-control
Предполагаю, что речь идет о возможности работы на самом раннем этапе загрузки системы. Могу ошибаться.
NTFS тоже регистрозависимая файловая система. Возможно стоит сделать как сделано в Windows (я не знаю детали, мб у вас уже так сделано, но судя по тексту нет), а не свои костыли. Полагаю в будущем это избавит от других проблем.
NTFS тоже регистрозависимая файловая система.
Нет. может использовать POSIX-семантику (см. флаг FILE_FLAG_POSIX_SEMANTICS), да — но это опционально. Чтобы обеспечить регистронезависимость (а это не так-то просто, вспомните хотя бы I/İ и ı/i у турков) в NTFS — есть таблицы и куча флагов.

Ничего подобного никто в BTRFS вкрутить не даст.
NTFS условно регистронезависимая ФС, т.е. имена файлов хранятся с учетом регистра, а вот поиск ведется с учетом файла $UpCase, в котором хранятся эквиваленты символов в верхнем регистре для всего Unicode. Более того, регистрозависимость можно включить для требуемых каталогов командой:
fsutil file setCaseSensitiveInfo
А RDP сервер уже есть у вас?
Можно использовать FreeRDP.
Он там без внц?

BTRFS и в убунту то ненадежна, а уж про ReactOS и подумать боюсь

В ReactOS будет совсем не тот драйвер, что в Ubuntu. Так что нестабильность Ubuntu тут не при чем.

"Нет, это был не я. Это был какой-то дурак. Я другой дурак" (Скотт Пилигрим)
В том плане, что хотя у убунта-бэйзет дистрибутивов большая аудитория, драйвера ФС все таки работают нестабильно. А к реактосу недоверия в плане стабильности ещё больше (может необъективно в данном случае, но все же).

Стабильность работы FS определяется в первую очередь конкретным драйвером и его версией для этой FS. То, что BTRFS была нестабильна в Ubuntu, не значит, что можно автоматически заявлять, что будет глючить и под Windows. А драйвер WinBTRFS разрабатывался специально для Windows, а уже потом его решили добавить в ReactOS.

С btrfs проблемы уровня дизайна (одно «лживое df» чего стоит). Бубунта никакого отношения к btrfs не имеет, потому что драйвер-то в апстримовом ядре.
драйвер-то в апстримовом ядре

Которое Линукс. А в ReactOS совсем не линуксовый драйвер.
Но ошибки дизайна (самой фс) распространяются на любые реализации спецификации.

А как по-вашему сделать "нелживые df" в copy-on-write ФС?

Иметь точное представление о том, сколько блоков (снизу там всё равно блоки!) выделено, а сколько занято.

Я говорю про ситуацию, когда мы сделали cow, и вдруг видим место, которое будет отличаться от того момента, когда мы в файл запишем. Я говорю про цифру реально свободных блоков прямо сейчас. Утрируя — сколько можно на диск записать в новый файл. Или дописать в существующий.
Иметь точное представление о том, сколько блоков (снизу там всё равно блоки!) выделено, а сколько занято.
Прекрасно. Имеем мы такое представление. Что дальше?

Утрируя — сколько можно на диск записать в новый файл.
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 — это только оценка…
Вы цепляетесь к мелким деталям. Ок, вот вам ожидания от df: показания df говорят о том, какого размера новый файл всё ещё можно записать на диск. Плюс-минус инлайны (не существенно).

У меня на btrfs раздел со стимом и меня страшно бесит, что df часто рапортует свободное место, которое меньше, чем разница между размером диска и размером файлов на нём. Сильно меньше. На сотню гигабайт (на терабайтном разделе) меньше. Потом всё нормализуется, но некоторое время — брешет.

И это раздражает.
Автоматически заявлять конечно нельзя. Но можно предполагать, что данный драйвер может быть хуже оттестирован, т.к. над Linux'ом (и под ним) работает несколько большее число людей, чем над/под ReactOS. И раз при тестировании на большей пользовательской базе не удалось отловить все проблемы — удастся ли это сделать меньшей команде, с меньшим числом пользователей и разработчиков? Так что наличие сомнений вполне объяснимо.
А драйвер WinBTRFS разрабатывался специально для Windows, а уже потом его решили добавить в ReactOS.
Начинать стоит с того, чтоб оно в принципе загружалось всегда и везде, а не в конкретной версии virtual-box и на 1 ядре. После этого, видимо, стоит перейти просто к стабильности работы, чтоб оно не падало от каждого чиха. А то вы 20 лет пилите систему, которая и не работает толком. Все эти ваши «а вот теперь с btrfs» — гроша ломанного не стоят, по причине того, что за 20 лет ваш «продукт» не стал даже относительно юзабельным.
Откуда эта токсичность? Вас будто насильно ей заставляют пользоваться.
Ну так помогите проекту, не важно, пиля новые фичи, исправляя баги или тестируя новые сборки.
КриптоПро с ключами надо прикрутить и 1С запустить. Уже можно будет на посы в магазины ставить, сетевые магазины могут и подтянутся.
А Вы, батенька, мечтатель :)
Почему же? Правильно рассуждает.
Разработчикам ReacOS можно будет заработать на коммерческой поддержке, как RedHat прям :D
Пилить в первую очередь те вещи, за которые будут платить.

Btrfs вот кому нужна? Пустая трата времени, хотя конечно не мне судить.
Кто будет платить?
Компании для которых использование ReactOS будет выгоднее лицензионной Windows.
За что будет платить?
За необходимый ему функционал и тех. сопровождение.
Если в ОС нет необходимого функционала для работы кассы/терминала — в её сторону даже смотреть не будут. Не говоря уж о том, чтобы оплачивать доработку.
Если ОС не может обслуживать штатный админ и требуется тех поддержка — эту ОС никто не будет использовать на кассах и терминалах.
Здесь была речь не про альфа-версию, а про релиз.
Это понятно.
Я про то, что либо ReactOS сразу будет пригодной для терминалов и не понятно за что платить, либо если она не пригодна — платить никто не будет.
Промежуточных значений в вашем мире не бывает? Например, есть терминалы, которые работают с Вистой или 7. И только с ними. Есть, которые с XP. И только с Хрюшкой.
Если сделать так, что условно любые виндоус терминалы будут работать, то это будет эпик вин и киллер-фича. Вообще, поддержку оборудование можно добавлять постепенно.
Нет, в моем мире не бывает промежуточных значений. Я не могу понять, кто и зачем будет доплачивать сколь либо значимые суммы команде ReactOS, когда можно тупо купить Windows 2009 POSReady и гарантированно получить работоспособную ОС.

P.S.
Стоит заметить, что уже сейчас ReactOS используется на терминалах. Пожалуй только отсутствие уверенности в стабильности мешает более массовому использованию.
Btrfs вот кому нужна? Пустая трата времени, хотя конечно не мне судить.

Кажется, это первая нормальная ФС с которой ReactOS может загружаться. Не знаю насколько оправдан выбор именно этой ФС, но работа была проделана явно не впустую.

Btrfs в первую очередь нужна как ФС с полным набором фичей — ссылки, ACL, аттрибуты и прочее. В FAT этого всего нет
Второй момент — это помогает фиксить баги в менеджере памяти. А недоделанный менеджер памяти это основная штука, которая мешает системе нормально работать

Нет проблем! ReactOS всегда рада новым разработчикам!

Проблемная ФС. В линухах уже ее выкидывают (deprecated).

И получается, что в Реакте нет (пока) ни одной нормальной современной ФС.

Хорошо бы что то быстрое типа HPFS/NSS или надежное типа JFS/NTFS. Но нужна хорошая реализация (КО)
Откуда информация про deprecated?
Я слышал только что её из RHEL выкинули
Она не «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
В линухах уже ее выкидывают (deprecated).

Кажется Вас сильно обманули.

Есть ещё шансы, есть.

Если Google рискнёт-таки с btrfs связаться, то и процент рынка, неожиданно, окажется подавляющим, и баги пофиксят… но пока не ясно — рискнёт или нет…
Эх, вот кто бы WinZFS запилил :)
А то только год назад показали что-то вроде демки и все, никаких новостей с тех пор.
An OpenZFS port of code to Windows is not likely in the foreseeable future
Ничего себе, а я искал и не нашел, думал заглохло все.
Однажды вдохновился проектом, но уже прошло 7 лет, а никаких существенных продвижек, кроме дизайна сайта, не наблюдается. :(
Я не понимаю реально смысла в BRTFS, разве не нашлось чего-то уже готового и надежного? ZFS? Ext4?
Дравйвер BTRFS для Windows на данный момент самый готовый и надежный среди других открытых. Надежнее только fastfat от Microsoft, который они недавно выложили. Но у нас менеджер памяти пока не до конца доделан, чтобы с ним работать
> fastfat

А это разве не «сферический драйвер в вакууме»?
В btrfs же есть всякие фишки вроде снепшотов, компрессии, checksums и тп. На мой личный взгляд, интереснее только ZFS.
Тут дело не в фичах, которые предоставляет ФС, а в драйверах и их совместимости с ядром.
Получается просто запихнули полуготовое, с наименьшими усилиями, но бесполезное с точки зрения практического применения
Очень интересный проект. А что там с поддержкой USB? Или я что-то пропустил и уже запилили.
Есть экспериментальная сборка с новым стеком USB

vk.com/wall-1086956_62644
Какие-то проблемы с этим? Почему в основную сборку не включаете?
Потому что ревью кода проходит очень медленно, недостаточно разработчиков, которые действительно понимают там каждую строчку кода.
А этот ваш Windows так умеет?

Для пользователей Windows в этом нет никакой нужды, как и, в скором времени, для пользователей всех остальных ОС.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий