Comments 36
Однако, потоки целостности можно включить для всего тома или выбранных файлов/папок. В этом случае REFS гарантирует, что считанные данные являются тем, что Вы когда-то записали. Если контрольная сумма не совпадает — REFS сообщит об ошибке и удалит файл
Вот этот момент мне непонятен все 10 лет существования REFS. Т.е. для зеркалированных данных на двух и более накопителях это конечно несомненный плюс.
А вот для одиночного жёсткого диска, где задокументировано 1*10^-14...1*10^-16 бит которые могут быть сбойными. Т.е. если по-человечески: 1 бит из считанных 11 Тб может быть невосстановимо сбойным. И ReFS кластер с этим битом тупо затрёт (в зеркалированном хранилище перепишет из зеркального накопителя).
Но терять кластер данных (4 Кб или 64 Кб, на выбор в случае REFS) это же не нормально? А если это кластер в базе данных SQL? Можно только гадать, что будет с взаимосвязями таблиц. Так?
Это как бы не одна цифра в базе повредится от пропажи этого бита.
Видимо в этом и была идея: если данные повреждены, избавляемся от них и восстанавливаем из реплики, а не думаем что все ок и работаем дальше с неверной цифрой в БД.
А одиночный диск для хранения чего-либо ответственного это не выход не только по причине вероятности сбойного бита, он может просто выйти из строя.
А потом внезапно выясняется что сбойный байтик в какой-нибудь пикче, видосике, недокаченном торенте или текстовом логе вообще всем до барабана, а вот наличие файлика куда как приоритетнее. Хотя это, конечно, мелочи на фоне отсутствия квот в серверной ФС, на фоне отсутствия шифрования и вообще внятного инструментария для решения проблем с этим очередным нинужно. Учитывая что в ажуре всё равно больше половины линуха, уже даже заядлые дотнетчики уходят хоть в линух, хоть в макось с этой помойки для домохозяек, не способной до сих пор внятно ни работать с консолью и пайпами, ни поддерживать хотя бы заявленные фичи на адекватном уровне, не разваливая что-нибудь каждый второй принудительный кумулятивный апдейт
Извините, мне кажется у Вас windowsmustdie в терминальной стадии. Каждой предметной области своя ОС, в каждой ОС что-то приходит, уходит и находятся проблемы - и это нормально, в конце концов это наша работа, разрабатывать, ломать и чинить.
А по теме: юзать NTFS не запрещают и судя по опыту ранее используемых ФС запретят еще не скоро, а если не пользоваться "помойкой для домохозяек" то ext4 и прочим ничего не угрожает.
Вы настолько привыкли к этой багомути, что чтобы не случилось "всё нормально" (хотя может в этой стране так принято, надо просто потерпеть), но если что-то происходит в других ОС, радостно улюлюкаете, как там всё плохо)))) По факту же я пишу с win10 pro и прекрасно вижу эту самую терминальную стадию. Незнаю, где тут ваша работа, может комменты строчить? Ну или я могу с вас спросить за недавнее обновление, либо за отломанный isolation=process для актуальных версий windows containers в десятке? Либо почему на такой клёвой ОС даже из консоли невозможно отформатировать microSD в FAT32 если она больше 32Гб чтобы ребёнку на старый планшет (который он обязательно добьёт) залить мультов.
Но терять кластер данных (4 Кб или 64 Кб, на выбор в случае REFS) это же не нормально?
Это нормально. Данные с ошибками не возвращаются накопителем, и не должны возвращаться файловой системой.
Другое дело, что МабутьЁльф напромтил вообще удаление файла…
проводил эксперименты с ReFS.
Делаю виртуалку vmware с Windows Server 2016. Добавляю виртуальных дисков. Из них делаю pool RAID1. На нем создаю диск в формате REFS. После форматирования и присвоения буквы записываю туда большой winrar-архив файлами. Если что - в архиве есть контрольная сумма для проверки его целостности.
Затем тушу виртуалку, открываю один из файлов в hex-editor, где-то в середине, где видны данные, несколько раз набираю на клавиатуре произвольный короткий текст поверх данных.
Сохраняю файл. Запускаю виртуалку. Монтирую пул, диск. Смотрю - файл на месте. Открываю его винраром и запускаю тест архива - обнаруживает ошибки CRC! То есть при нарушении данных вы их можете исправить ПОТОМ, но при чтении они не исправятся сами. Поправьте меня если ошибаюсь.
Для исправления ошибок и перевода тома в исправное состояние нужно было запускать "проверку и восстановление" из настроек томов Storage Spaces.
Сейчас уже точно не помню, но, по-видимому, при аналогичном сценарии на linux с ZFS-диском RAID1 ошибок при проверке архива небыло. Подключал zfs-диск как самба-шару к компу и можно было из винды проверять файл, который на виртуалке линукс лежал.
ZFS восстанавливает прозрачно, тут сомнений нет. Просто счетчик ошибок контрольных сумм делает +1
Выглядит и правда странно. И ZFS, и BTRFS контролируют целостность данных при чтении, а для борьбы с фоновым протуханием битов есть scrub. Возможно ли, что контроль целостности данных в риалтайме нужно отдельно включить?
А бит исправлялся в файле образа, или путём его монтирования и исправления файла через драйвер файловой системы?
А вы сломали файл лежащий поверх зеркала, или половинку зеркалированного блока ФС?
В первом случае поведение вполне ожидаемое: вы сохранили новое содержимое, которое корреткно отчексамилось и заменило старое. То что при этом кто-то записал мусор в середину файла архива — ФС отследить никак не может.
Во втором поведение действительно странное.
Изменялся диск виртуальной машины. Можно считать, что там повылазили bitrot за много лет одновременно). Где хваленые refs контрольные суммы данных? Ожидал, что при работе с файлом ошибка будет на лету исправлена. Не произошло.
Затем тушу виртуалку, открываю один из файлов в hex-editor, где-то в середине, где видны данные, несколько раз набираю на клавиатуре произвольный короткий текст поверх данных.
делал аналогичный тест с zfs, «портил» данные на одном диске с помощью fio.
всё прошло нормально, данные считались корректно, выросли счётчики ошибок контрольных сумм на «порченном» диске.
и реальные случаи silent data corruption у меня были, zfs ловил.
Никаких интересных фич, связанных с доступом к файловой системе как к базе данных (что предполагалось реализовать когда-то в WinFS) здесь, как я понимаю, нет?
WinFS (short for Windows Future Storage) was the code name for a canceled data storage and management system project based on relational databases, developed by Microsoft and first demonstrated in 2003.
Я джвадцать лет ее жду.
Я не то чтобы жду, но идея интересная (ну и я сам себе запилил простенькую систему тегов на ADS). Джвадцать лет назад вполне могло не хватать вычислительных ресурсов для комфортной работы подобной технологии. Кто знает, может у МС еще остались мысли по реализации чего-то подобного?
Помнится, тут на Хабре один пользователь рассказывал, как у него гигабайты каких-то файлов (или картинок? не помню точно), прилетающих извне, распиханы по десяткам тысяч папок, в каждой из которых по несколько сот тысяч файлов. И это все надо с чем-то еще синхронизировать. И что единственный вариант поиска файла по совокупности критериев, предоставляемый API Windows - это использовать FindNextFile. Который вроде как читает долго-долго вычитывает содержимое папки и в общем все ужасно тормозит.
Почему он не хотел хранить какие-то метаданные (название, размер, дата создания и т.п.) файлов в отдельной базе данных - не помню (может, из-за концепции единого источника, или из-за необходимости какой-то мониторинг активности писать, чтоб в базе актуализировать информацию при изменении содержимого). Если б WinAPI предоставлял какие-то возможности баз данных, можно, наверное, было бы достичь необходимой функциональности без сторонних решений. Сейчас же для того, чтобы просто посмотреть, сколько папка C:\Windows весит, нужно ждать с минуту, пока там все посчитается. А так бы одним запросом в базу данных, и ответ готов.
NTFS — и есть база данных. Папка — это индекс.
Вы сравните, сколько занимает первичный подсчет, и сколько — повторный. За счет отсутствия операций ввода-вывода (данные уже попали в кеш) разница на винчестерах достигала пары порядков.
С базой данных будет или то же самое или она сожрет еще несколько (десятков) ГБ под кеши, индексы, планы запроса и вот это вот все. Ну и еще юзер получит уникальную возможность убить наглухо производительность компа, понасоздавав левых индексов или удалив нужные.
Плюс сама БД, обслуживающая ФС, будет лежать поверх ФС, что не прыти ей добавит, а конкуренции за IO.
можете взять sqlite уже сейчас (уже давно могли, в общем-то), и будет быстрее чем просто файлы.
Можно, но это не интегрировано с ФС, на работу с которой ориентирован весь другой софт.
Еще можно держать БД параллельно ФС, но тогда каждая операция с ФС должна как-то отражаться в БД. А это требует встраивания в ядро ОС. Всякие файловые органайзеры, обзоры которых на Хабре были, на такое не способны. Они даже на использование ADS не способны, хотя это вообще штатная фича NTFS. Или имена файлов коверкают для размещения в них метаинформации, или надеются что юзер кроме как предлагаемой софтиной, ничем больше с ФС работать не будет.
Resilient File System во многих отношениях лучше, чем NTFS. Например, NTFS поддерживает максимум 256 терабайт хранения, а ReFS предлагает поддержку до 35 петабайт.
Однако у ReFS нет некоторых функций, которые есть в NTFS, включая сжатие системы и поддержку шифрования. В ReFS также отсутствует поддержка дисковых квот и съёмных носителей.
Как-то не очень "лучше".
Квоты тоже довольно специфическая вещь в домашних системах.
А зачем эти петабайты в домашней системе? Майки опять хотят привязать пользователей к новой проприетарной технологии?
А типа NTFS это открытый и доступный всем стандарт?
По крайней мере, задокументированный сторонними открытыми реализациями (ntfs-3g и ntfs3 от paragon). Это не отменяет того, что ФС постепенно устаревает, и хорошо бы добавить какие-то еще варианты (которых в целом не мало и явно не уступающих по возможностям даже ReFS) в стандартную поставку, но майки всё равно гнут в сторону проприетарных продуктов, которые снова придется долго и упорно ковырять, прежде чем появится какой-то сторонний драйвер хотя с возможностью чтения. Понятно что можно и с btrfs загрузить десятку, но всё же хочется видеть возможности из коробки.
А зачем эти петабайты в домашней системе?
Остальные улучшения: ну да, ну да, пошли мы на…
В мире Linux же никто не возбухает, что файловая система ext4 поддерживает тома до миллиона терабайт, а спокойно используют её дома.
10-ка поддерживает ReFS. Отформатировать в ReFS не может, но работать с уже отформатированными может. 11, скорее всего, тоже может работать. Так что значит "Windows 11 получит новую файловую систему ReFS"? Появится возможность отформатировать? Систему на ReFS ставить нельзя, насколько я помню.
Отформатировать тоже может. Загрузитесь в режиме восстановления и - вуаля! - ReFS доступна в команде format, во всяком случае на Win 10/11 Pro (не Воркстейшн) вполне работает.
Насколько я понял, речь идёт о возможности установки на ReFS. В версии 3.7 вроде хардлинки добавили, а значит Винда может установиться и загрузиться. Зачем - другой вопрос :)
Windows 11 получит новую файловую систему ReFS