>>>В NTFS нет FAT. Там MFT, для начала. А что понимается под "распределенных FAT"?
> DFS понимается. ?! Это ж сетевая ФС, которая всего лишь позволяет шаре по одному и тому же пути указывать на несколько физически разных машин. Кэп намекает: сетевые ФС есть и под *никсы, если что. Только вот при чем тут FAT/MFT, особенно распределенные? oO
> FAT хоть как понимай хоть, как MFT хоть как BSDM
Мне было бы интереснее понять как FAT относится к сетевой файловой системе DFS.
И это, а комент про $Bitmap вы проигнорировали. Это по вашему так и надо современные ФС делать? Или чего?
> - дело разработчика как он эту область назовет.
Ну, кроме названия у них еще и несколько разная логическая организация. В нтфс был некий бзик что все - файлы. Сам $Mft - тоже файл. Самое оригинальное то что он содержит запись указывающуб на сам себя :)
> 12 лет - ни единого разрыва :-D.
А еще можно 12 лет на запорожце поездить для полноты ощущений. Если уж никуда не торопиться и не гнаться за комфортом и параметрами - вполне вариант :)
>>>У CoW-образных ФС в этом плане есть изрядный плюс.
> Теоретический.
И практический. Физику не обманешь. Когда на диск пишется файл, традиционная журналирующая ФС для честного журналирования должна записать его *дважды*: один раз - в журнал, второй - коммит задуманного в основную часть ФС. Ну или как компромисс позволяющий избежать просадки скорости, при журналинге только метаданных - не получится обеспечить честную транзакционность по принципу "все или ничего", и будет возможна ситуация когда облом случился в тот момент когда файл был наполовину старый и наполовину новый. И это не получится ни откатить назад, ни завершить операцию до конца. Из-за отсутствия потребных для этого данных. Такой подход (ordered журналирование и т.п. в терминах EXT3, etc) обеспечивает только корректное состояние метаданных при крахе, но данные файла (в лучшем случае) корректны только при дозаписи файла. А вот при перезаписи - файл может оказаться наполовину старой и наполовину новой версией, что вообще-то чревато неюзабельностью такого файла. Честное журналирование такой проблемы не имеет но писать 2 раза данные файла на диск для этого - не прикольно. Copy-on-write файловая система - по сути один большой журнал. Запись на физический девайс делается 1 раз, а откат к прошлому состоянию в случае проблем делается простым забиванием на то что не успели дописать. При том это применимо как к метаданным, так и к данным, что возможно благодаря логик работы CoW (копирование данных при записи). Фокус в том что CoW файловая система всегда производит запись в *новое* место, не разрушая старые данные. Даже при перезаписи файлов. Поэтому в случае краха всегда доступно старое состояние файла (и файловой системы заодно). Этот подход имеет свои грабли (фрагментация из-за копирования в сторонку того что изменено/дописано), но его плюсы перевешивают а грабли можно до некоторой степени пролечить. В итоге получается скорость файловой системы с журналированием только метаданных + надежность/транзакционность файловой системы с полным журналированием. И куча плюшек нахаляву типа возможности делать множественные снапшоты просто, быстро и не через зад. Ведь если старое состояние файла не дестроили - можно без проблем показать файл и в том виде каким он был до модификации. Просто проигнорив дозаписанное после интересующего момента. Оно же в сторонке лежит и забить на него проще простого :)
Итого? CoW выглядит красиво и эффективно. Шаг вперед в технологиях, имхо.
> Практический - снос крыши кэшу.
Мсье дурак? Кэш не сохраняется при крахах, поэтому все что я говорил - это уже то что происходит при фактической записи на физический девайс, опосля всяких там кешей и прочая (логика журналинга насильно сбрасывает даже аппаратные кеши накопителей, если это не получается - беда, хана журналингу: толку от него не будет, т.к. журналинг полагается на фактическую запись в девайс нужных данных). Кэширование журнала или чего там еще - может только поднасрать. Извините, но если случится крах, данные для отката операции или ее доведения до конца брать надо с энергонезависимого накопителя, а?! Потому что кеш при потере питания или ребуте будет безжалостно просран (в крутых контроллерах поэтому бывают кеши с батарейками, но это отдельный вопрос). Итого? Чтобы журналирование сработало, данные должны быть физически записаны на накопитль, откуда их потом можно будет взять, правда? Ну и какой тогда кеш?! В случае честного журналинга и классической ФС - писать надо два раза. На физический носитель. Убедившись что он ни в коем случае не врет что записал данные. Сначала - в область журнала, потом в область основной файловой системы :). Как максимум читерят и не пишут 2 раза данные. Но при этом возникает возможность ситуации с полуперезаписанными файлами, особенно в случаях когда файл перезаписывается поверх самого себя своей же измененной версией.
> NTFS журналит кластеры для отмены -
Да щаззз. Насколько я знаю, нтфс в дефолтном виде журналит только метаданные. Поэтому ничто не мешает возникнуть ситуации когда облом случился при перезаписи файла, на середине операции. Файл при этом будет испорчен (и это проблема ВСЕХ файловых систем не делающих полное журналирование, а полное журналирование в классических ФС убивает скорость минимум в 2 раза, т.к. данные файла надо писать дважды).
> в лучшем случае это быстрее CoW, в худшем медленнее.
CoW обеспечивает скорость близкую к скорости без журналирования (как и "читерские" неполные журналирования только метаданных). Но зато "журналирует" еще и данные (независимо от того в какой момент случился крах, всегда есть старое состояние файла т.к. у CoW запись не деструктивна, в отличие от). Если на классической ФС журналить все (для аналогичного уровня неубиваемости данных при крахе) - скорость убьется минимум в 2 раза, т.к. в классическом дизайне журнала их надо писать 2 раза. Сперва в журнал, потом на диск.
> Собсна все ответы есть у Руссиновича- что и как у NTFS.
Есть. И в NTFS ничего такого супердупер интересного. Обычная такая ФС, по технологиям - уровня EXT3/XFS примерно. Только они тоже уже давно не новье и не круть.
> Журнал у неё много старше всех ext-подобных.
Но не менее бестолков - в общем то обычный классический журнал, более-менее :)
> Она ей наслаждается.
...да, неспеша... :)
> Сравнивать Fuse реализацию за три корки хлеба и реализацию
> кода FS в ядре ? Это нереально.
Так я про ядерную реализацию, если что. Она тоже скоростью не страдает. И фрагментируется весься даже.
> FS 12-летней давности не может быть суперсовременной. Но остальные по прежнему чет
> лепят и считают, что зоопарк FS у Linux уберсовременный.
Из уберсовременных там Btrfs. Остальные - просто фс. Какойнить XFS или EXT4 - ничего шедеврального, но работают и довольно резво. А хоть и обладая озвученными минусами традиционых ФС, как то или журналинг только метаданных с риском получить полупереписанный файл, или миниум двукратная прсадка скорости записи на полное честное журналироание.
> Да ни фига - отсталый он, все эти фишки тырятся у более современных
> реализаций.
Btrfs хорошо так потырило - все лучшие достижения из разных мест понадергали :). Да, они все по отдельности были и до. Но объединить все в 1 ФС почему-то никто до них не додумался. И, главное, майкрософту в ближайшие годы будет нечем ответить толком на подобные ФС. Их фс 15-летней древности - это не ответ.
> Слив № 10000 поздравляю с юбилеем.
Поздравляю с сливом. Даже двукратным. Первый - про DFS, второй - про кэш vs журналирование.
