Комментарии 33
В виде DevDrive ReFS уже какое-то время доступна.
Да и вот это не совсем правда
ReFS не может быть использована на диске, с которого загружается ОС
Девбилд в начале года ставился на ReFS если совершить финт ушами. 24h2 я не проверял
Установил, кстати, потыкать 24h2 на ReFS. Огорчился задумчивости и затыкам, там где ОС установленная на ntfs работает без проблем.
Например при выключении пароля локальной учетной записи окно смены пароля повисло на 10 минут, да и в целом, ловил странные и не воспроизводимые фризы на ровном месте. Поигрался и хватит
Вот это ускорение в обычных версиях и будет заметно лишь на DevDrive,
Не так уж часто я копирую гигабайтные файлы. А вот в чем возникает потребность, так это в принципиально новом подходе к файловой системе. В некоторых функциях, свойственных базам данных. Например чтобы у файла кроме уникального имени были неуникальные теги, по которым также можно искать, сортировать и фильтровать файлы. Что-то можно проэмулировать используя ADS, но не всё, и не всегда это удобно. Для каких-то возможностей нужны специальные файловые менеджеры или плагины к существующим (и тоже далеко не всегда получается удобно).
Пытались сделать WinFS как замену NTFS. Там, насколько я помню, файловая система больше напоминала БД. Проект закрыли.
В NTFS есть streams в которых можно хранить дополнительные данные
P.S. прочитал, что в посте про это упомянуто. Но тут дело не в ФС, а в том, что файловые менеджеры не внедрили поддержку
блочное клонирование в ReFS увеличивает скорость копирования небольших файлов размером 1 Мбайт на 18%. При увеличении размера файла прирост производительности становится еще более заметным, так как файловая система не копирует весь объем данных, а лишь создает ссылки на них.
А это мне видится очень опасным явлением, ты думаешь при копировании, что там данные, копия данных, а там только ссылки...
Повреждается основной объект и кирдык данным, независимо от того сколько копий их сделано....
Или я не правильно понял, и это не точный перевод...
Дедупликация похожим образом работает во многих файловых системах скорее всего. Возможно, это можно отключить?
Копия файла на тот же диск - хреновый бекап всё равно.
Бакап от сбоя - да, хреновый.
А вот версионный бакап - вполне себе живучая идея, и да, иногда проще забакапить исходник отдельным файлов, чем поднимать систему версионирования.
На это CoW-filesystem никак не повлияет, кроме того, в какой момент будет затрачено время на копирование. Ничего не знаю про этот ReFS но Btrfs ещё и место сэкономит, храня только те куски, которые фактически разные.
А вот версионный бакап - вполне себе живучая идея
Так версионный никуда не девается же. Скопировав файл в четыре разных места, вы получаете четыре разных линка + четыре файла с дельтой от первоисточника. И вот это линк на объект + дельта и формируют итоговый результат, который вы получаете при обращении к копии.
Да, но... т.к. zfs/btrfs более актуальны для хранилок, а там всё ещё чаще HDD, то история про покрывающийся битыми секторами диск всё ещё более актуальна чем мгновенно превратившийся в тыкву SSD. И вот тогда настройки дедупликации ZFS типа `set copies=2` очень даже актуальны и позволяют и места сэкономить, и скорость "копирования" обеспечить. Хоть с одним диском, хоть с массивом. И контроль целостности файлов сверху позволяет убедиться что пока ты новый диск добавляешь на замену умершему, на него наливается наиболее целая копия данных, а не набор дырок собранных с двух равномерно избитых дисков.
А есть ещё варианты работы через снапшоты, когда вроде и файлы почти те же, но и полноценный откат почти мгновенно и почти на халяву, которые для винды не будут доступны, видимо, никогда (как и быстрые развёртывания обновлений)
И самый хардкор - разворачивание всяких билдовалок и рабочих энвайрментов, где могут переливаться туда-сюда ежедневно сотни тысяч файлов...
Ну а по сабжу... вообще непонятно что это и зачем оно нужно, особенно в условиях когда оно не даст просто перекинуть хард с данными с умершего ПК на любой другой утюг (на котором не факт что будет стоять распоследняя винда). И вообще наелись уже "динамических дисков" над NTFS с той же песней, где они теперь... а теперь они официально Obsoleted, потому что проблем больше чем смысла
Форматировать обычный накопитель в ReFS, по-прежнему, можно только в Pro for Workstation, но не в более привычных Home и Pro.
Заголовок некорректен: добавили не ReFS, а поддержку блочного клонирования в ReFS.
так как файловая система не копирует весь объем данных, а лишь создает ссылки на них.
Так суть копирования и состоит в пояалении материальной копии, а не ссылки на оригинал, которую и в 1-ом виндовсе можно было делать. Если оригинал грохнется, сильно помодет ссылка на грохнувший файл?!
Если оригинал изменится, то копия все равно останется нетронутой. В предельном случае будет два разных файла, но если оригинал изменился не весь - часть общих блоков останется в единственном экземпляре
Если оригинал повредится - это немного другая ситуация, отслеживание повреждений должно происходить по контрольным суммам в метаданных самой ФС
"....лишь создает ссылки на них" в рамках одного тома - это принципиально.
При копировании между томами/дисками выполняется физическое копирование блоков.
Обновление Windows 11 2024 Update (24H2) впервые добавило в потребительскую операционную систему поддержку файловой системы ReFS
ReFS появилась ещё в Windows 8.1, а затем перебралась в 10. Позднее, с каким-то из обновлений десятки, отключили GUI создания раздела ReFS, но сам функционал (создания) до сих пор оставался (ну, по крайней мере в Windows 11 22H2 ещё был), как и возможность пользоваться созданными разделами (про поддержку загрузки системы тоже уже давненько заявляли, но на тот момент с этим были проблемы; как обстоят дела с этим сейчас — не знаю). Так что ничего не изменилось, кроме версии самой ReFS.
Несмотря на все эти красивые таблички с функционалом ФС и уже солидный возраст, для рядового пользователя она до сих пор не годится. Проприетарщина, которую производитель не может нормально сопровождать сам и другим делать этого не позволяет. Даже с эппловской APFS дела обстоят лучше.
У ReFS есть ряд проблем.
1) Отсутствие обратной совместимости. Каждая новая версия Windows, видя том ReFS, автоматически обновляет версию ReFS до актуальной. После этого том уже не будет работать в предыдущих версиях Windows. Следствие: если у вас есть какой-то LiveCD для спасения данных в случае сбоя установленной Windows, вам нужно этот LiveCD обновлять вместе с Windows.
2) Если ReFS сожрёт данные (или они по какой-то причине повредятся), их можно восстановить утилитой ReFSUtil. Это сильная сторона ФС. Проблема в том, что эта утилита до сих пор работает лишь с ReFS версии 3.9. В то время, как Windows 11 24H2 уже использует ReFS 3.14.
Собственно именно эти две причины пока удерживают меня от перевода хранилища на ReFS.
К хорошим новостям: в какой-то версии даже добавили поддержку жёстких ссылок. И некоторые наркоманы даже устанавливают Windows на раздел ReFS, хотя официально это не поддерживаются, а последние версии Windows просто вылетают с ошибкой на этапе OOBE.
что угодно, лишь бы не нативная поддержка ext4, ага.
Обновление Windows 11 выглядит интересным, особенно с добавлением ReFS, которая раньше была только в серверных версиях. Теперь копирование файлов станет быстрее благодаря блочному клонированию, что полезно для тех, кто часто работает с большими объемами данных. Но жаль, что ReFS не поддерживает шифрование и сжатие, да и чтобы воспользоваться ей, нужно будет форматировать диски.
Но жаль, что ReFS не поддерживает шифрование
И давно оно у вас не поддерживает? https://learn.microsoft.com/ru-ru/windows-server/storage/refs/refs-overview
Оно какое-то Шредингеровское:


Но возможно имеются в виду разные вещи
Мне кажется, что это вообще чатгпт-шный комментарий.
В Windows 11 24H2 добавили поддержку блочного клонирования в ReFS