Comments 67
Пересчитать такие девайсы можно по пальцам рук.
Любое счётное множество можно пересчитать по пальцам рук!
У меня возникли сомнения, что, возможно, таких устройств больше 5. Но не во всех Surface-ах, этот драйвер есть.
А уж если вспомнить про 2Z, можно бесконечно заниматься болтологией вместо обсуждения темы, да?
Я-то как раз, в свойственной мне доброй манере, обсуждаю статью: в виде шутки намекаю на то, что есть выражение «по пальцам одной руки», означающее, что предметов до пяти и «по пальцам двух рук», когда их до 10. А «по пальцам рук» никаких ограничений не накладывает.
Тогда как вы, пыхтя от злобы, занимаетесь как раз болтологией.
"Приложение Xbox не позволяет устанавливать игры на том ReFS." Это потому что эта штука использует шифрование файлов игр. Причем это не стандартное шифрование NTFS, там особый формат специально для этого. По этому никуда кроме NTFS микрософт не даст игры поставить. Драйвер который расшифровывает это очень интересен - это самомодифицирующийся драйвер ядра. Код заскремблирован в нем. Перед вызовом функций расшифровки - код дескремблируется - отрабатывает - скремблируется обратно.
А логика?
логика около сериализации типо какой-то, вроде защита наверно не знаю
а хотя ответ нашелся в zfs опять же, ZFS. Тоесть это типо перчатки(Resilvering and scrub (array syncing and integrity checking)(примерно около того есть и еще какой-то скрембл вобщем читать придётся)) тоесть та работа которая нужна на уровне доступа к дереву, чтобы произвести проверки, синки и прочее что предусматривает Xbox решение ), файловая система это дерево, устройство Xbox это продукт для пользователя с файловой системой, поэтому в перчатках надо предусмотреть fsck и прочие штуки по тонкой работе с деревьями(тоесть данными на жестком диске)
где-то выдают перчатки по запросу, где-то тот кто обходит одевает перчатки и обходит - делает проверки )
Вообще я не уловил логику. Если там своё шифрование на уровне драйвера, не зависящее от NTFS, почему это не должно работать на других ФС.
Предполагаю - то что было сделано для Xbox цельно втянули в виндовый магазин. Типа от пиратов.
возможно, я немного не в тему, но вот такой вопрос: там, где систему удалось установить на раздел с этой файловой системой, наблюдается ускорение работы, по сравнению со "всеобщим стандартом"?
Мне думается, лучше купить SSD, ну а там уже если какая-то разница и есть, она будет незаметна для не вооружённого бенчмарками пользователя.
Пытаться ускорять таким образом медленный диск с операционной системой это явно не очень хорошая идея, лучше заменить сам накопитель на более быстрый.
По скорости ReFS заметно быстрее, как минимум, при копировании данных в пределах одного тома, за счёт блочного клонирования.
Нашлось такое сравнение
Блин, такое ощущение, что winbtrfs и то больше готова для продакшена, чем вот эта.
А есть понимание, почему так происходит? Как будто Resilient FS не такой и resilient. То есть ощущение, что она готовилась под облака. Именно поэтому она восстанавливает повреждения на уровне блока, а не отдельного файла. И в какой-то момент стало понятно, что там она и не нужна. А использует ли MSFT её в своём облаке?
То есть ощущение, что она готовилась под облака.
ReFS первоначально готовилась под Windows Longhorn (который потом стал Vista), MS обещала ФС, совмещённую с базой данных, которой можно будет отдавать SQL-подобные запросы для эффективного поиска файлов. Но что-то пошло не так.
А в чем её преимущества? Я вот очень хочу встроенные в FS теги, доступ к файловой системе как к базе данных и т.п. Однако вот в википедии читаю
Многие возможности NTFS не поддерживаются в ReFS, включая именованные потоки файлов, NTFS Distributed Link Tracking (DLT), короткие имена файлов (формат 8.3), сжатие файлов[11], шифрование на уровне файлов Encrypting File System, транзакции NTFS, жёсткие ссылки, extended attributes и дисковые квоты
Это как вообще? Даже жесткие ссылки, которым сто лет уже, и то не поддерживаются? От ADS отказались? То есть это не развитие а какой-то откат назад.
А вообще напрашивается мысль о какой-то единой open-source файловой системе, которая могла бы использоваться и в винде, и в линуксе, и в других ОС. По аналогии с тем как движок Хрома используется в куче браузеров, в том числе и в майкрософтовском.
А в чем её преимущества?
Эффективное сжатие. Дедупликация на уровне ФС (не нужен Windows Server, как в случае с NTFS). Повышенная устойчивость к сбоям и самопочинка. Возможность хранить контрольные суммы для каждого файла. И так далее.
Однако вот в википедии читаю
Устаревшая информация. Жесткие ссылки уже поддерживаются с какой-то версии. Сжатие тоже. Остальное не особо нужно/критично.
По техническим темам лучше читайте англовики, там оперативнее обновляют данные.
То есть это не развитие а какой-то откат назад.
Это никогда и не было развитием NTFS. Это совершенно иная ФС, спроектированная с нуля. Поэтому там и нет всякого легаси типа имён 8.3
8.3 это да, давно уже не надо. А контрольные суммы - полезная вещь, рад что до этого додумались. Считаю что основные хеш-суммы должны быть на уровне ФС и по возможности сами обновляться при сохранении файлов (инкрементальные алгоритмы), это тоже одна из моих хотелок вместе с тегами, а также очень удобно для всяких p2p сетей (хотя подозреваю что в ReFS используется что-то свое узкоспециализированное).
Вроде, подсчёт сумм заметно замедляет работу.
Ну, и как указано в статье, в случае использования зеркала, файл с неверной суммой будет записан на зеркало, хотя должно быть строго наоборот.
Это понятно. Всякие SHA-2 действительно требуют полного пересчета при изменении хотя-бы одного байта файла. Но разным файлам нужны разные контрольки (а некоторым и вовсе никакие не нужны, кроме разве что обязательной системной). У множества файлов, которые по смыслу "только для чтения" (книги, фотки, музыка, фильмы, исполняемые бинарники) контролька считается один раз при появлении файла в системе. А именно такие файлы являются основным контентом для файлообмена.
Можно ввести в атрибуты файла теги вида "контролька+таймштамп", и обновлять контрольную сумму только тогда, когда она необходима и таймштамп отличается от текущего для файла. А есть еще инкрементальные алгоритмы, для них проще: при переписывании блока вычитаем его старую сумму (тем же XOR) из общей суммы и добавляем сумму нового блока.
ReFS, всё-таки, создавалась под всякий энтерпрайз, где она будет навёрнута поверх Storage Spaces, а не под домашний диск с торрентами. Хотя, на 22-терабайтном диске с торрентами мне удалось за счёт одной лишь дедупликации сэкономить 5 ТБ, что приятно. Ну а покупать второй такой же диск ради зеркалирования торрентов откровенно жаба душит.
Вроде, подсчёт сумм заметно замедляет работу.
В более-менее современных процессорах есть аппаратные блоки CRC и SHA. Тут больше накопитель может стать узким местом, если это дешманский SSD, например. Хотя суммы и считаются поблочно, если файл большой, подсчёт может затянуться.
Вот, гляньте:
$ time sha256sum "A Rainy Day in New York.mkv"
4a63fcec9ddf20f17ac23ba58a3dfa76787ea81588d54f5035641e56d68a57af A Rainy Day in New York.mkv
real 3m11.042s
user 0m12.069s
sys 0m6.159s
Процессор всё это время был нифига не нагружен. Не берите дешманские SSD, господа.
Да, майки предупреждают, что подсчёт контрольных сумм может увеличить задержку ввода-вывода
If integrity streams are enabled, all write operations become allocate-on-write operations. Though this avoids any read-modify-write bottlenecks since ReFS doesn't need to read or modify any existing data, file data frequently becomes fragmented, which delays reads.
Depending on the workload and underlying storage of the system, the computational cost of computing and validating the checksum can cause IO latency to increase.
А также ещё есть проблема в том, что если диск не зеркалирован, то вместо содержимого файла вернётся ошибка.
If ReFS is mounted on a non-resilient simple space or a bare drive, ReFS will return an error to the user without returning the corrupted data.
Так а разве дедуп не на контрольных суммах реализован? А как тогда?
Зачем просто контрольные суммы? Что оно вам даст этим? Ну узнаете что файл побился через какое-то время, а дальше что? Если нет копии данных, от контрольных сумм толку нет. Если хочется защитить данные - то нужно добавлять блоки коррекции ошибок. От злономеренных действий типа шифровальщика или удаления поможет COW файловая система.
ZFS могла бы стать единой с единым тулкитом менеджмента и отката снапшотов(у ней есть крутые на сегодняшний день для бсд решения откатов и прочего, и сама она без них достаточно удобная), удобнее фс я пока не видел, но на линуксе не пользовался ею
У Соляриса он еще лучше прям интегрирован, любое измнение можно записать вместе с окружением и изменениями на сколько помню, и какой-то механизм просто подтянет окружение под изменение(причем сам сейв затронет только срез)
graphics-stack/ вот тут можно посмотреть как слой создаётся после создания такой точки к ней можно вернуться
тоесть она почти всегда откатываемая
если сравнивать эту историю с системой с грабом то система сграбом имеет минус, если сравниваем с виндой то она могла бы такое реализовать, вся кодовая инфраструктура предраспологает реализовать такой механизм в винде
Про ZFS ходят мифы, что она требовательна к объему памяти. Хотя, я встречал мнение, что если в ней не включать фичи, требовательные к памяти, то потребление будет терпимым.
В Linux ещё есть Bcachefs, которая, вроде как, и развивается как "нативная замена ZFS", но у неё шибко специфический автор. Который задолбал Линуса до такой степени, что тот готов уже выкинуть эту ФС из ядра.
зфс я смог воспользоваться ток на фрибсд, в солярисе типо такой но СолярисФс, а в опениндиана это зфс, и да на опениндиане может нагрузить, но и там организация(самой системы) не как на фряхе(ветка чуть другая standards), тут я не смогу оценивать, а в реализации на фряхе вообще классно всё на момент 14.2 сужу
Оффтоп. А почему Bcachefs так взлетела, когда есть btrfs, которую использует например в Synology, для своих надёжных NAS...
к btrfs многие относятся плохо потому что так исторически сложилось. когда шапка выпустила btrfs это была дико проблемная и сырая фс которая невозвратно ломалась от каждого чиха. позже, когда шапка забила на btrfs, сусевцы взялись за неё и переписали чуть больше чем полностью, теперь это хорошая, надёжная, фичастая фс пригодная для серьёзного прода (и кроме синолоджи её хорошо так юзает например нетфликс в своём серьёзном и высоконагруженном проде), но люди злопамятные и если условный вася когда-то 10 лет назад прочитал на форуме что btrfs это гавно он будет в этом уверен до смерти.
а bcachefs привносит ещё дополнительные фичи которые не доступны в btrfs (например ssd кэш которого в btrfs нету (кстати в синолоджи он есть, но у них для этого свой софт который они никому не дают)), а так же обещания кента что его фс "АРХИТЕКТУРНА ЛУШШИ!" что вроде бы как и правда, но всё же немного спорно.
к сожалению bcachefs кмк повторит судьбу reiserfs по схожим причинам, если автор не может или не хочет идти в ногу с апстримом то его поделие так и останется игрушкой для парочки гиков, не более. а жаль, я ждал и надеялся.
фейсбук, нетфликс, оксфорд аэролоджи, синолоджи.. крупные ребята не читают комменты икспердов на пикабу, опеннет и хабр и потому не знают что btrfs в их высоконагруженных продакшн серверах оказывается для них не годится..
нетфликс в своём серьёзном и высоконагруженном проде
использует ZFS на FreeBSD
Последний раз когда я проверял btrfs, она просто конско тормозила с образами дисков для виртуалок. И у неё ещё до сих пор проблемы с raid5 или 6, вроде как. в ZFS со всем этим проблем нет. С другой стороны, btrfs нативная для линукса и с неё тот замечательно бутится. С ZFS забутиться удастся только с помощью извратов в initramfs. Администрирование btrfs тоже по ощущениям как-то более нативно что ли, чем вычурные и многословные конструкции zfs. Понятия 'датасетов' тоже в zfs слишком абстрактны, в btrfs imho это сделано лучше. Наконец, zfs умеет в нативное шифрование, а в btrfs несмотря на как-то раз обещанное шифрование, до сих пор ничего. В btrfs есть дефрагментация всего чего только можно, в zfs ничего.
Поэтому приходится держать обе две.
А вообще очень показательно, как sun и далее сообщество смогли в zfs, линуксовое сообщество смогло в btrfs, а целый большущий микрософт в свой похожий велосипед -- не смог.
Конские тормоза на btrfs я ощущаю только во время scrub, но и на zfs было так же.
А raid 5 и 6 в целом не вызывают доверия, разве что для нешибко важных данных. Впрочем относительно недавно их перестали помечать как непригодные, на домашнем nas я сконвертировал зеркало в raid5 и за пару лет проблем не ощутил, на проде я такое решение применять не готов ни в btrfs ни mdadm ни zfs.
Алсо мне в сравнении btrfs и zfs очень нравится то что в btrfs я могу любую комбинацию дисков сконвертировать в любую другую так как нет абстракции в виде zdev. Но есть и обратная сторона монеты, в отличии от zfs к сожалению btrfs не позволяет выключить сжатие если уже включил (имею ввиду разжать уже сжатые данные, хотя сменить алгоритм сжатия позволяет) и не имеет аналога zvol (хотя нечто подобное всё же имеет).
Мы пахали, я и трактор.
Sun и сообщество - zfs
oracle, suse и сообщество - btrfs
sgi и сообщество - xfs
IBM - и сообщество - jfs
Samsung и сообщество - f2fs
Только к refs сообщество не примазалось, исходников им не дали =)
не очень она и взлетела
А вообще напрашивается мысль о какой-то единой open-source файловой системе
напрашивается мысль о какой-то единой open-source файловой системе
но разве zfs не имела проблем из-за своей несовсем опенсорсной лицензии? Не совсем опенсорсный CDDL просто не совместим с опенсорсной GPL насколько я помню.
да и какая она единая если работает только в нескольких ОС, так ещё и поставляется отдельно..
тот же btrfs (прошу не принимать это заявление всерьёз) имеет драйвер и для винды и для макоси..
opensource =/= GPL
драйвер и для винды и для макоси..
https://github.com/openzfsonwindows/openzfs/releases
https://github.com/openzfsonosx/openzfs-fork/releases/tag/zfs-macOS-2.3.0
каюсь, был не прав. интересно насколько это работоспособно (но не настолько интересно чтобы качать винду или макось).
Я, если честно, вообще не вижу применения в домашнем окружении (ну, кроме разве что TrueNAS или хоумлабы для "поиграть").
Фат
Но реальность бьёт в пах
Любая девушка-сисадмин легко преодолеет все эти препятствия
После 13 лет разработки ReFS так и не готова заменить NTFS