Pull to refresh

Comments 48

И грузиться с неё нельзя.
Это начальный превью релиз, потом все добавят.
«we will implement ReFS in a staged evolution of the feature: first as a storage system for Windows Server, then as storage for clients, and then ultimately as a boot volume. This is the same approach we have used with new file systems in the past»
Они забыли добавить «iser» после RE ☺
У меня создалось впечатление, что это недо-ZFS для данных.
Печально, что опять придётся под Линукс ждать хорошей поддержки этой ФС, как уже было с NTFS. Разве что Майкрософт откроет спеки…
Она ещё очень и очень долгое время останется чисто серверной, так что линуксовый драйвер не так уж необходим. Опять же во время написания первых линуксовых дров для NTFS в ядре не было такой вундервафли как FUSE.
+100 к FUSE!!!(как же я про нее забыл)
какие только виртуальные файловые системы на ней не реализуют. Скажем SSHFS какая прелесть!
Прелесть ровно до того момента, как порвется соединение.
Наверное, у меня кривые руки, но решить проблему с тотальным зависанием в этом случае мне не удалось до сих пор…

Но FUSE да, вещь крутая.
На нестабильном соединении — вообще не стоит применять виртуальные сетевые ФС, в большинстве случаев после таймаута — получите зависание.
На таком канале поддается некоторой настройке NFS, но это тоже не панацея.
В вашей ситуации применяю ssh для удаленного подключения к сессии screen и scp для копирования файлов в обоих направлениях. Для командных сценариев на python модуль paramiko.
> решить проблему с тотальным зависанием в этом случае мне не удалось до сих пор

umount -f /mountpoint

И монтируем заново, если нужно.
Как то не тянет ReFS на серверную, в свете упрощений и выкидывания «ну совсем ненужных для сервера ФС» фич (шифрование, квоты, транзакции и т.п.). Скорее я бы сразу назвал её ФС для домашней сферы (ну и для мелкого бизнеса).
Читайте оригинал. Убирают только рудимент, ФС от этого функционально не пострадает
Что то не печалит это меня нисколечки. Возможно дело в особенностях работы и пр. деятельности. В скольких случаях использовал сегодняшний, стабильно работающий, драйвер под ntfs (ntfs-3g) вообще считаю по пальцам: притащили usb-хард расформатированный под ntfs. забрал данные с диска из под погибшей у кого то винды, убил винлокер при помощи livecd от касперского(тот что на основе gentoo сделан)… и наверно все за последние полгода.
Согласен — тем кто работает с использованием двойной загрузки (win/lin) может и нужно = но в таком случае обычно создается раздел для обмена данными — сейчас можно и под ntfs, раньше был fat32
Еще момент: обычно внедрение новой fs у microsoft идет весьма неспешно(как было уже с ntfs) + инерция пользователей(весьма осмотрительная в данном случае) — недоверие к этаким нововведениям. В результате имеем несколько лет времени за которые в режиме реверс-инженерии уже создадут(если будет сильно нужен) какой нибудь ReFS-4g — хотя бы для работы в режиме «только чтение».
Ализар, такой Ализар. NTFS уже была на вполне себе клиентской NT4 Worksation в 96 ом году.
UFO just landed and posted this here
Очень любопытно, вот они квоты порежут и как мне пользователям выделять место на общем диске тогда? Да и глупость с отрезанием хардлинков это вообще бред как мне один файлик спрашивается положить в 10ть папок. Я конечно согласен что NTFS устарела но менять наточенное шило на красивую т прочную но туповатую титановую палочку (согласно этому релизу) не вижу смысла.
если аналогия (zfs, btrfs) верна, то квоты никуда не исчезнут, просто перейдут из ведения непосредственно ФС к разделам, которые изменять/создавать будет изрядно проще.
Тоже стало интересно насчет квот — нужная вещь, особенно на терминальных серверах. Но ваша фраза «просто перейдут из ведения непосредственно ФС к разделам, которые изменять/создавать будет изрядно проще» мне совершенно не понятна. ФС в принципе на разде лежит, а не наоборот. Нафига мне создавать разделы если мне нужно лимитировать пользователей по занимаемому пространству?
ZFS уже не «лежит» на разделе диска. ZFS использует для своего пула разные диски, разделы, файлы, а в фразе имелись в виду разделы самой ZFS, а не разделы жесткого диска.
Зачем вам хардлинки, если есть симлинки и junction points?
Хардлинки нужны и самой винде (весь сервисинг и компонентизация на них завязаны). Вот только меня поражает сколько людей (в том числе и в комментариях к исходному посту на b8) не понимают разницы между «выбросили» и «еще не реализовали, но собираемся». Точно так же как поиск файлов по object id, альтернативные файловые потоки и многое другое.

Ну а пока не реализовали, NTFS никуда не делась (и да, по элегантности с этим старичком может соперничать разве что ZFS — в посте Чена вообще ничего про «неэлегантность» нет): если нужны возможности NTFS (те, которые еще не реализованы в ReFS) и не нужны НОВЫЕ возможности ReFS — никто не заставляет пользоваться новой ФС только потому что она новая (об этом тоже есть в оригинальном посте).
Можете поподробнее написать про сервисинг и компонентизацию? Речь про папку winsxs?
Да речь о ней — там фактически одни хардлинки и лежат. Сервисинг (Windows Update) использует еще и KTM (те самые транзакции, которые тоже «выбросили»):
That leaves two more goals. As for platform stability, this is achieved by some of the ways that Microsoft is using TxF in its own technologies. There are three core features in Windows Vista and Windows Server «Longhorn» that now make use of Transactional NTFS: Windows Update, System Restore, and Task Scheduler. All of these use TxF to write files to the file system within the scope of a transaction in order to handle rollback/commit in case of any exceptions, such as a system reboot due to a loss of power. If you’ve ever experienced a loss of power right in the middle of Windows Update, you know this can leave your system dead and in need of a fresh installation. But now that Windows Update uses TxF, if this same situation occurs on your Windows Vista system, the computer can recover by rolling back the transaction when the system reboots. By adopting TxF internally, Microsoft has helped make its own operating system more stable.


Собственно на все эти «выброшенные» возможности ФС завязано столько возможностей самой винды, что последняя стадия в «first as a storage system for Windows Server, then as storage for clients, and then ultimately as a boot volume» означает поддержку в ReFS всех фич NTFS. Более того, есть серьезные основания предполагать, что именно из-за их отсутствия загрузка с ReFS и не поддерживается: не думаю, что прилинковать к winload еще и ReFS это такая уж сложная задача, а после winload уже будет полноценный драйвер и никому уже не нужно знать какая там файловая система.
А кстати кто-нибудь в курсе чем закончилась эпопея с WinFS которую обещали сделать в Висте, потом отложили до Server 2008? Похоронили ее?
Мне кажется, что они как-то тихо замяли эту тему.
UFO just landed and posted this here
UFO just landed and posted this here
>>но при этом опять наступая на те же грабли: основная среда — unmanaged, а «поверх» неё вертится managed среда (для C# и VB).
Чем вам грабли? Удобность ничуть не упала, зато увеличилась скорость +!!! возможность использовать в нативном коде!!!
> как всегда всё опять упёрлось в совместимость и Microsoft в очередной раз делает из конфетки какашку.

Делать обратно несовместимые вещи могут позволить себе только те, у кого рынка — с гулькин нос.
Рано или поздно от поддержки legacy надо отказываться, иначе не будет развития.
Хотя в этом плане есть подвижки — гипервизор встроили в клиентские системы и постепенно выносят уровенить совместимости в ВМ.
WinFS не была файловой системой — это была надстройка на NTFS, части которой всплыли в вин7 в виде библиотек.
Когда я анализировал ReFS я увидел, что она напоминает NTFS, но многих её возможностей там нет. Действительно, ни файловых потоков, ни расширенных атрибутов. Зато сохранилась технология точек повторной обработки (reparse points), а на её основе сделаны символьные ссылки и точки монтирования каталогов и томов.

Я думал, что хотя бы файловые потоки будут добавлены позже. Оказывается, нет. Жаль, это шаг назад.
Где они использовались-то? Я знаю буквально 1-2 софтины, каким-то боком использующие эту сомнительную функциональность.
Я знаю буквально 1-2 софтины, каким-то боком использующие эту сомнительную функциональность.

Вирусы с антивирусами? :)
Альтернативные потоки используются, к примеру, Internet Explorer-ом при сохранении файлов из интернета (и Windows Explorer отказывается напрямую запускать такие файлы).
А, вон оно где хранилось. В макоси эти данные в расширенных атрибутах хранятся (posix-совместимых). Соответственно, могут быть скопированы, если таргет-система тоже их поддерживает (даже если не hfs), а в винде только с ntfs на ntfs максимум.
Ну extended attributes в ReFS тоже пока не поддерживаются. В общем фраза «no longer supported» меня несколько смущает, но я СИЛЬНО удивлюсь, если к моменту «then ultimately as a boot volume» все недостающие фичи (кроме, пожалуй, коротких имен) не будут реализованы.
Новая ФС! А сделать в винде полную поддержку длинных путей (>255), которые заложены в NTFS, это видимо очень сложно и не нужно.
В винде ЕСТЬ полная поддержка длинных путей (>260). Изменять контракт на размер буфера, который раньше был фиксированным — это не просто ломать совместимость, это напрашиваться на срывы буферов с последующим исполнением кода
Другое дело, что почему то сам Windows Explorer все не хочет понимать длинные имена — вот это для меня загадка.
Поддержка то как бы есть. Специальными программами можно копировать файлы с длинными путями, но вот Explorer уже такие папки не поддерживает. При это не придумано даже путей миграции к длинным именам. Когда переходили нам имена файлов >8.3, то механизм все поддержки старыми программами был все таки найден, хоть и кривоватый, но все же. А тут выходит Vista, который суждено было быть ОС изгоем из-за огромного числа нововведений, но поддержку длинных путей так и не сделали.
Хотя да, я сейчас подумал и понял, почему эксплорер не поддерживает длинные имена. У shell интерфейсов есть куча методов, которые возвращают путь, который традиционно имел максимальную длину в MAX_PATH. Из-за этих методов сам эксплорер не может иметь путь длиннее, чем MAX_PATH: к примеру, программа спрашивает текущий путь, а shell не может его вернуть.
Вот интересно, альтернативные потоки сделают как в ntfs? :)

5 лет спустя…
На ReFS всё ещё нельзя поставить систему, и она рассматривается только как FS для бекапов…
Подождём следующую FS от MS?

Sign up to leave a comment.

Articles