Комментарии 63
А почему поиском по маске занимается драйвер? Разве это не одинаковая для всех файловых систем функция (перебрать файлы и отобрать подпадающие под маску)? Или это дает возможности каких-то оптимизаций?
В принципе, все запросы к директориям делаются через один и тот же IRP, обычно их обрабатывает один метод в драйвере
docs.microsoft.com/en-us/windows-hardware/drivers/ifs/irp-mj-directory-control
NTFS тоже регистрозависимая файловая система.Нет. может использовать POSIX-семантику (см. флаг FILE_FLAG_POSIX_SEMANTICS), да — но это опционально. Чтобы обеспечить регистронезависимость (а это не так-то просто, вспомните хотя бы I/İ и ı/i у турков) в NTFS — есть таблицы и куча флагов.
Ничего подобного никто в BTRFS вкрутить не даст.
fsutil file setCaseSensitiveInfo
BTRFS и в убунту то ненадежна, а уж про ReactOS и подумать боюсь
"Нет, это был не я. Это был какой-то дурак. Я другой дурак" (Скотт Пилигрим)
В том плане, что хотя у убунта-бэйзет дистрибутивов большая аудитория, драйвера ФС все таки работают нестабильно. А к реактосу недоверия в плане стабильности ещё больше (может необъективно в данном случае, но все же).
Стабильность работы FS определяется в первую очередь конкретным драйвером и его версией для этой FS. То, что BTRFS была нестабильна в Ubuntu, не значит, что можно автоматически заявлять, что будет глючить и под Windows. А драйвер WinBTRFS разрабатывался специально для Windows, а уже потом его решили добавить в ReactOS.
драйвер-то в апстримовом ядре
Которое Линукс. А в 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
— это только оценка…У меня на btrfs раздел со стимом и меня страшно бесит, что df часто рапортует свободное место, которое меньше, чем разница между размером диска и размером файлов на нём. Сильно меньше. На сотню гигабайт (на терабайтном разделе) меньше. Потом всё нормализуется, но некоторое время — брешет.
И это раздражает.
Разработчикам ReacOS можно будет заработать на коммерческой поддержке, как RedHat прям :D
Пилить в первую очередь те вещи, за которые будут платить.
Btrfs вот кому нужна? Пустая трата времени, хотя конечно не мне судить.
Если ОС не может обслуживать штатный админ и требуется тех поддержка — эту ОС никто не будет использовать на кассах и терминалах.
Я про то, что либо ReactOS сразу будет пригодной для терминалов и не понятно за что платить, либо если она не пригодна — платить никто не будет.
Если сделать так, что условно любые виндоус терминалы будут работать, то это будет эпик вин и киллер-фича. Вообще, поддержку оборудование можно добавлять постепенно.
P.S.
Стоит заметить, что уже сейчас ReactOS используется на терминалах. Пожалуй только отсутствие уверенности в стабильности мешает более массовому использованию.
Btrfs вот кому нужна? Пустая трата времени, хотя конечно не мне судить.
Кажется, это первая нормальная ФС с которой ReactOS может загружаться. Не знаю насколько оправдан выбор именно этой ФС, но работа была проделана явно не впустую.
Нет проблем! ReactOS всегда рада новым разработчикам!
И получается, что в Реакте нет (пока) ни одной нормальной современной ФС.
Хорошо бы что то быстрое типа HPFS/NSS или надежное типа JFS/NTFS. Но нужна хорошая реализация (КО)
Я слышал только что её из RHEL выкинули
Итог:
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).
Кажется Вас сильно обманули.
В Сузи еще осталась, но %рынка не тот
А то только год назад показали что-то вроде демки и все, никаких новостей с тех пор.
An OpenZFS port of code to Windows is not likely in the foreseeable future
А этот ваш Windows так умеет?
Для пользователей Windows в этом нет никакой нужды, как и, в скором времени, для пользователей всех остальных ОС.
ReactOS теперь запускается с BTRFS раздела