Вопрос о правильном размере кластеров в NTFS

Alek> Дык а у меня все эти три диска - SATA. Насколько я понимаю каждый на отдельном контроллере?
Alek> Температура упала на три градуса.

Эх, SATA всё ещё сильно проигрывает SCSI. Даже SAS, ИМХО, немного проигрывает. У меня на работе Sun Ultra 45 для разных performance tests используется. там 4 проца, один SCSI Ultra 320, один SAS и мы прикупили большой SATA. Так SATA самый медленный. На Dell Power Edge 1950 у нас SAS и SATA стоят. Так SAS при последовательном чтении всего диска выдаёт устойчиво выше 90 МБ/с (он, правда на 15,000 оборотов). А SATA выдаёт пиками до 90, но начиная с 45. Правда, он на 7,500.

А, блин, как я вспомню канальную архитектуру на IBM/360 и 370. Или сейчас, как пойдёшь к нашим mainframe-щикам, так у них IO просто летает всегд и в параллель. Никакие SCSI не сравнятся.

pokos> Да. Однако, не многие знают, что IDE позволяет синхронизировать шпиндели накопителей. Раньше, когда сектора на диске занимали фиксированные места, это бывало полезно.
Да, для всяких стрипов и зеркал было знатно. Но я сейчас стараюсь покупать диски, которые очередь команд имеют. Они немного могут сами без контроллера работать. Выручает.

DSB>> Да хватит смеяться то )))) Во-1, память на кэширование структур используемых папок будет всегда, иначе и выделение буферов под преобразование видео не гарантировано. Ты же знаешь принцип работы кэша.
Mishka> Ложное утверждение. Выделение буферов — нормальная операция. Кэширование — использование свободной памяти, которая может быть отобрана операцией выделения памяти. И говорю именно потому, что знаю, как это работает.
OK. Допустим кэш у нас - ноль. Тогда и твоя рутовая папка не будет кэшироваться Да и вообще будет не до сжатия видео )
Напоминаю предмет спора : ты утверждаешь, что принципиально писать именно в корневую папку, дескать это сильно разгружает систему, а я говорю, что это настолько несоразмерно малая по вычислительной нагрузке операция, что на фоне видеосжатия не окажет никакого влияния на процесс. Ну в самом деле, какая нафиг разница : D:\video.dat или D:\Video\video.dat ?

Mishka> Во-2, рутовая это папка или в глубине фаловой структуры, с т.з. кэша - пофигу, кэшировать придётся одинаковое количество данных.
Mishka> Ложное утверждение. Директория — тот же файл, которые приходится держать открытым или кэшировать. Т.е. данных больше. Насколько — зависит от того, сколько файлов в директории.
Данных больше на ничтожную величину. Скорее всего на 1K. В современной ОС таких структур тысячи. Хорош уже ))) Что рутовая это будет папка, что не рутовая - с т.з. NTFS пофигу. В кэше будет то, что часто меняется, т.е. в основном структуры MFT, остальное будет ритмично сбрасываться на диск. Там ещё и журналирование есть, тоже отключать будем ? )

Mishka> Во-3, если мы уж занимаемся такой "тонкой" настройкой, то не забывай, что ОС постоянно пишет то в реестр, то на диск и ей пофигу, какие приложения и что в это время делают.
Mishka> Ей не пофигу. В частности, поставь работу с не removable устройствами и ОС будет туда писать намного меньше. И с реестром можно разобраться. В частности запретить (если разрешены) performance counters. Ну и, если работать не из под администратора, а из под обычного пользователя, то и записи в реестр сократятся. Можно запретить и logging многих событий, тоже уменьшиться.
Дык можно, кто спорит. В данном конкретном примере смысла всё это делать нет, т.к. процесс идёт на отдельном томе.

DSB> OK. Допустим кэш у нас - ноль. Тогда и твоя рутовая папка не будет кэшироваться Да и вообще будет не до сжатия видео )

Для доступа к любой директории, сначала доступаются к рутовой, потом открывают директорию первую в пути, потом вторую, потом ... и так по полному пути. Мало того, что директория на диске может лежать в произвольном месте, что приведёт к полётам гововки многократным. А рутовая директория всегда начинается в однм месте. Если файлов в руте мало, то всё в этом месте и лежит. т.е., даже, если и не кешируется, то ровно одно обращение к диску.

DSB> Напоминаю предмет спора : ты утверждаешь, что принципиально писать именно в корневую папку, дескать это сильно разгружает систему, а я говорю, что это настолько несоразмерно малая по вычислительной нагрузке операция, что на фоне видеосжатия не окажет никакого влияния на процесс. Ну в самом деле, какая нафиг разница : D:\video.dat или D:\Video\video.dat ?

Да. Это принципиально ускоряет. При сильной фрагментации диска, может раза в два.

DSB> Данных больше на ничтожную величину. Скорее всего на 1K. В современной ОС таких структур тысячи. Хорош уже ))) Что рутовая это будет папка, что не рутовая - с т.з. NTFS пофигу. В кэше будет то, что часто меняется, т.е. в основном структуры MFT, остальное будет ритмично сбрасываться на диск. Там ещё и журналирование есть, тоже отключать будем ? )

Не пофигу. Рутовая всегда специальная. Ну и поучи как NTFS работает — есть такая книжка Amazon.com: Inside the Windows NT File System (9781556156601): Helen Custer: Books — в качестве технического обзора хороша. Если не ошибаюсь, тётечка один из разработчиков NTFS.

DSB> Дык можно, кто спорит. В данном конкретном примере смысла всё это делать нет, т.к. процесс идёт на отдельном томе.

Ну, чем нагрузка на систему IO меньше, тем лучше.

Mishka> Эх, SATA всё ещё сильно проигрывает SCSI. Даже SAS, ИМХО, немного проигрывает.

не путаешь? SAS по идее не должен проигрывать SCSI-320 даже в случае один_диск-одни_контроллер

Mishka> Эх, SATA всё ещё сильно проигрывает SCSI.... А SATA выдаёт пиками до 90, но начиная с 45. Правда, он на 7,500.
Мне вообще непонятны технологические причины появления SATA. Маркетологические-то понятны... Тот же UDMA-100 ни одним даже нынешним диском (окромя SSD ) не может быть загружен на 100%.
Поменяли б интерфейс с ТТЛ на лавандос, можно было бы и ускорить раза в три-четыре без гемора.
Mishka> А, блин, как я вспомню канальную архитектуру на IBM/360 и 370.
Ну, тогда каждый байт стоил больших денег. Люди думали, ночами не спали.

Mishka> Для доступа к любой директории, сначала доступаются к рутовой, потом открывают директорию первую в пути, потом вторую, потом ... и так по полному пути. Мало того, что директория на диске может лежать в произвольном месте, что приведёт к полётам гововки многократным. А рутовая директория всегда начинается в однм месте. Если файлов в руте мало, то всё в этом месте и лежит. т.е., даже, если и не кешируется, то ровно одно обращение к диску.
Зачем ты это всё пишешь? Да хоть 10 уровней вложенности! Обход дерева идёт на этапе открытия файла, когда процесс кодирования видео ещё не пошёл. Открыли файл - всё, ОС запомнило где он начинается в MFT и её уже наплевать на все вышележащие папки.

DSB>> Напоминаю предмет спора : ты утверждаешь, что принципиально писать именно в корневую папку, дескать это сильно разгружает систему, а я говорю, что это настолько несоразмерно малая по вычислительной нагрузке операция, что на фоне видеосжатия не окажет никакого влияния на процесс. Ну в самом деле, какая нафиг разница : D:\video.dat или D:\Video\video.dat ?
Mishka> Да. Это принципиально ускоряет. При сильной фрагментации диска, может раза в два.
Про фрагментацию говорить не надо. Она в общем случае мало зависит от ветвистости файловой структуры. И при полном отсутствии сабфолдеров можно обеспечить любой уровень фрагментации. А с учётом сказанного абзацем выше обсуждать уровень фрагментации и разбросанности по диску элементов каталогов вообще нет смысла.

DSB>> Данных больше на ничтожную величину. Скорее всего на 1K. В современной ОС таких структур тысячи. Хорош уже ))) Что рутовая это будет папка, что не рутовая - с т.з. NTFS пофигу. В кэше будет то, что часто меняется, т.е. в основном структуры MFT, остальное будет ритмично сбрасываться на диск. Там ещё и журналирование есть, тоже отключать будем ? )
Mishka> Не пофигу. Рутовая всегда специальная. Ну и поучи как NTFS работает — есть такая книжка .. в качестве технического обзора хороша. Если не ошибаюсь, тётечка один из разработчиков NTFS.
Мне и Русиновича с Соломоном хватит. Файл открыт - при его заполнении обновляется элемент файла в MFT и заполняется область данных. В 2 места одновременно надо писать (а фактически в большее из-за журналирования и т.п.). Вне зависимости от типа папки. Другое дело, что фактически запись в область MFT жёстким диском должна происходить реже из-за кэширования. Повторяю - нет никакой разницы.

Harsky> не путаешь? SAS по идее не должен проигрывать SCSI-320 даже в случае один_диск-одни_контроллер

Не знаю. У меня только одна машинка, которая все три имеет. Ну и это тесты по нашему продукту, если БД размещаем на разных дисках. Правда, для очень болььших БД (120 ГБ прироста за пару часов), всё равно только на SATA. Все остальные вылетают по нехватке памяти раньше.

DSB> Зачем ты это всё пишешь? Да хоть 10 уровней вложенности! Обход дерева идёт на этапе открытия файла, когда процесс кодирования видео ещё не пошёл. Открыли файл - всё, ОС запомнило где он начинается в MFT и её уже наплевать на все вышележащие папки.

Блин, можешь всё-таки подучишь как работают ФС? А обновлять заголовок файла, который только в директории, каждый раз, когда flush делают бабушка будет? Почему ты думаешь, в лине часто монтируют ФС с запрещением отслеживания последнего времени доступа, а оставляют только время модификации?

DSB> Про фрагментацию говорить не надо. Она в общем случае мало зависит от ветвистости файловой структуры. И при полном отсутствии сабфолдеров можно обеспечить любой уровень фрагментации. А с учётом сказанного абзацем выше обсуждать уровень фрагментации и разбросанности по диску элементов каталогов вообще нет смысла.

Афигеть. Учись читать. Обеспечь мне полную фрагментацию диска, когда только корневая и один файл в ней. А так же поучи, как выделяется место под каталог, когда диск заполнени в начале.

DSB> Мне и Русиновича с Соломоном хватит. Файл открыт - при его заполнении обновляется элемент файла в MFT и заполняется область данных.

Ну так поучи, когда и как таблица MFT расширяется и когда кэшируется. А так же структуру элементов каталогов.

И ты сильно путаешь обновление структур ФС и кэширование этих элементов.

DSB> В 2 места одновременно надо писать (а фактически в большее из-за журналирования и т.п.). Вне зависимости от типа папки. Другое дело, что фактически запись в область MFT жёстким диском должна происходить реже из-за кэширования. Повторяю - нет никакой разницы.

Есть. Почитай девелоперов, не только Марка. Про Марка можешь не рассказывать, он, вообще-то из CMU.

Harsky>> не путаешь? SAS по идее не должен проигрывать SCSI-320 даже в случае один_диск-одни_контроллер
Mishka> Не знаю. У меня только одна машинка, которая все три имеет.
ясно. мне тоже проверить не на чем, слишком разные диски scsi и sas, чтобы мог сделать правильные выводы

DSB>> Зачем ты это всё пишешь? Да хоть 10 уровней вложенности! Обход дерева идёт на этапе открытия файла, когда процесс кодирования видео ещё не пошёл. Открыли файл - всё, ОС запомнило где он начинается в MFT и её уже наплевать на все вышележащие папки.
Mishka> Блин, можешь всё-таки подучишь как работают ФС? А обновлять заголовок файла, который только в директории, каждый раз, когда flush делают бабушка будет? Почему ты думаешь, в лине часто монтируют ФС с запрещением отслеживания последнего времени доступа, а оставляют только время модификации?
По факту не мне надо учить матчасть. Ты читай мои посты полностью. Нафига обвинять меня незнанием того факта, что в заголовке файла надо обновлять его размер, а также выстраивать цепочку кластеров, если я обзацем ниже это самое и говорю ("Файл открыт - при его заполнении обновляется элемент файла в MFT и заполняется область данных.")?
Будем утверждать, что для того чтобы обновить заголовок файла надо каждый раз пробежаться по цепочке вышестоящих элементов каталогов? Ась? Не дадо? Ежу понятно, что НЕ НАДО. Так какая разница корневой это фолдер или не корневой после того, как файл открыт на запись?

DSB>> Про фрагментацию говорить не надо. Она в общем случае мало зависит от ветвистости файловой структуры. И при полном отсутствии сабфолдеров можно обеспечить любой уровень фрагментации. А с учётом сказанного абзацем выше обсуждать уровень фрагментации и разбросанности по диску элементов каталогов вообще нет смысла.
Mishka> Афигеть. Учись читать. Обеспечь мне полную фрагментацию диска, когда только корневая и один файл в ней.
Не преписывай мне бредовых утверждений, которые потом так удобно опровергать. Про фрагментацию закончили, т.к. я нигде не говорил, что сравнивается вариант чистого диска с одним файлом в корне с засранным диском с кучей фолдеров и фрагментацией. Ты меня с кем-то путаешь.

Mishka> А так же поучи, как выделяется место под каталог, когда диск заполнени в начале.
Вообще у меня стойкое ощущение, что ты знаешь структуру FAT и судишь о работе NTFS по аналогии. В любом случае непонятно, как тебе в этом случае помогает рутовый фолдер. Ты сам-то готов углубиться в структуры NTFS и на пальцах показать, где я не прав? Или будешь камуфлировать реальные знания ссылками на умные книжки, которых скорее всего сам в руки не брал?

DSB>> Мне и Русиновича с Соломоном хватит. Файл открыт - при его заполнении обновляется элемент файла в MFT и заполняется область данных.
Mishka> Ну так поучи, когда и как таблица MFT расширяется и когда кэшируется. А так же структуру элементов каталогов.
Mishka> И ты сильно путаешь обновление структур ФС и кэширование этих элементов.
Ну и напиши в чём я не прав. Если бы ты сам в этом действительно разбирался (читал девелоперов), то уже давно бы зарыл меня терминами из структуры NTFS и тогда мне действительно пришлось бы отвечать тем же. А пока я слышу только ритуальные выкрики "учи матчасть, студент". Это не серьёзно.

DSB> По факту не мне надо учить матчасть. Ты читай мои посты полностью. Нафига обвинять меня незнанием того факта, что в заголовке файла надо обновлять его размер, а также выстраивать цепочку кластеров, если я обзацем ниже это самое и говорю ("Файл открыт - при его заполнении обновляется элемент файла в MFT и заполняется область данных.")?

Да, буду. Хотя и не всегда. Дело в том, что иногда надо и у директории кой-чего обновить.

DSB> Будем утверждать, что для того чтобы обновить заголовок файла надо каждый раз пробежаться по цепочке вышестоящих элементов каталогов? Ась? Не дадо? Ежу понятно, что НЕ НАДО. Так какая разница корневой это фолдер или не корневой после того, как файл открыт на запись?


Так расскажи мне, что такое файл открыт с точки зрения как ФС, так и ОС.


DSB> Не преписывай мне бредовых утверждений, которые потом так удобно опровергать. Про фрагментацию закончили, т.к. я нигде не говорил, что сравнивается вариант чистого диска с одним файлом в корне с засранным диском с кучей фолдеров и фрагментацией. Ты меня с кем-то путаешь.

Пока бред от тебя идёт. Я сказал, что сказал. При наличии файла и директорий фрагментация достигается. При наличии одного файла для захвата, да в корневой — обеспечь мне фрагментацию. Или просто признайся, что не можешь.

DSB> Вообще у меня стойкое ощущение, что ты знаешь структуру FAT и судишь о работе NTFS по аналогии. В любом случае непонятно, как тебе в этом случае помогает рутовый фолдер. Ты сам-то готов углубиться в структуры NTFS и на пальцах показать, где я не прав? Или будешь камуфлировать реальные знания ссылками на умные книжки, которых скорее всего сам в руки не брал?

В отличии от тебя, я знаю, как это работает изнутри по исходному коду. Чтобы не было вопросов, расскажи-то мне, когда MTF может сама быть фрагментированной.

DSB> Ну и напиши в чём я не прав. Если бы ты сам в этом действительно разбирался (читал девелоперов), то уже давно бы зарыл меня терминами из структуры NTFS и тогда мне действительно пришлось бы отвечать тем же. А пока я слышу только ритуальные выкрики "учи матчасть, студент". Это не серьёзно.


Я тебе уже написал. Ты сильно путаешь кеширование с работой самой MTF. Но, если надо и терминологией могу пободать. Только я знаю, что Руссинович работу кэшей особо не рассматривает.

DSB>> По факту не мне надо учить матчасть. Ты читай мои посты полностью. Нафига обвинять меня незнанием того факта, что в заголовке файла надо обновлять его размер, а также выстраивать цепочку кластеров, если я обзацем ниже это самое и говорю ("Файл открыт - при его заполнении обновляется элемент файла в MFT и заполняется область данных.")?
DSB>> Будем утверждать, что для того чтобы обновить заголовок файла надо каждый раз пробежаться по цепочке вышестоящих элементов каталогов? Ась? Не дадо? Ежу понятно, что НЕ НАДО. Так какая разница корневой это фолдер или не корневой после того, как файл открыт на запись?
Mishka> Да, буду. Хотя и не всегда. Дело в том, что иногда надо и у директории кой-чего обновить.
"Не всегда", "кой-чего". Почему бы тебе не называть вещи своими именами? Ну что можно обновить в фолдере? На ум приходит только дата модификации. Любого разработчика, которому придёт в голову бредовая идеи обновлять этот атрибут ДО того, как файл будет ЗАКРЫТ, надо увольнять без выходного пособия. Ес-но в NTFS такого бреда быть не может.

Mishka> Так расскажи мне, что такое файл открыт с точки зрения как ФС, так и ОС.
Зачем? Чтобы в ответ услышать "Копай дальше"? У меня нет столько свободного времени. Если есть конкретное возражение, то говори.

DSB>> Не преписывай мне бредовых утверждений, которые потом так удобно опровергать. Про фрагментацию закончили, т.к. я нигде не говорил, что сравнивается вариант чистого диска с одним файлом в корне с засранным диском с кучей фолдеров и фрагментацией. Ты меня с кем-то путаешь.
Mishka> Пока бред от тебя идёт. Я сказал, что сказал. При наличии файла и директорий фрагментация достигается. При наличии одного файла для захвата, да в корневой — обеспечь мне фрагментацию. Или просто признайся, что не можешь.
Если размер файла будет сравним с размером тома, то велика вероятность, что он тоже будет записан не неприрывной цепочкой LCN. Почему? 1. $MFTMirr находится в середине тома и делит его пополам. 2. Фйлы протоколирования NTFS и прочие метаданные тоже могут разместиться неудачно (уж не знаю, где они стандартно размещаются физически).

Давай-ка я ещё раз уточню предмет спора. Имеем чистый том NTFS c кластером в 64K. Я создаю на нём пару пустых вложенных фолдеров (да хоть 10), видео-файл будет писаться в самый глубокий фолдер. Ты утверждаешь, что это хоть как-то измеримо помешает производительности ввода-вывода ?

Mishka> В отличии от тебя, я знаю, как это работает изнутри по исходному коду. Чтобы не было вопросов, расскажи-то мне, когда MTF может сама быть фрагментированной.
Нет, подменять предмет дискуссии не надо. Хочешь - открывай другую.

Mishka> Я тебе уже написал. Ты сильно путаешь кеширование с работой самой MTF. Но, если надо и терминологией могу пободать. Только я знаю, что Руссинович работу кэшей особо не рассматривает.
Рассматривает вообще-то. И рассматривает "особо" - есть отдельная глава. Вообще спор не о кэше. Но если я что-то путаю, то знающему человеку нетрудно будет конкретно сказать что именно.

DSB> "Не всегда", "кой-чего". Почему бы тебе не называть вещи своими именами? Ну что можно обновить в фолдере? На ум приходит только дата модификации. Любого разработчика, которому придёт в голову бредовая идеи обновлять этот атрибут ДО того, как файл будет ЗАКРЫТ, надо увольнять без выходного пособия. Ес-но в NTFS такого бреда быть не может.

Не верно. Время обновляется не во время закрытия файла, а во время модификации. Файл может быть открыт, изменение произведено, а файл всё ещё не закрыт. Дата обновления должна уже быть новая.

DSB> Зачем? Чтобы в ответ услышать "Копай дальше"? У меня нет столько свободного времени. Если есть конкретное возражение, то говори.

Дык, подумай. Я тебе уже много говорить не буду. Кеширование с работой ФС соотноястяся слабо — ФС должна работать и без кеширования. Подробностей, пардон, не будет. NDA надо мной висит и будет висеть, пока я в этой компании работаю.

DSB> Если размер файла будет сравним с размером тома, то велика вероятность, что он тоже будет записан не неприрывной цепочкой LCN. Почему? 1. $MFTMirr находится в середине тома и делит его пополам. 2. Фйлы протоколирования NTFS и прочие метаданные тоже могут разместиться неудачно (уж не знаю, где они стандартно размещаются физически).

Зеркало можно и смещать. Ну и протоколирование у тебя не полное.

DSB> Давай-ка я ещё раз уточню предмет спора. Имеем чистый том NTFS c кластером в 64K. Я создаю на нём пару пустых вложенных фолдеров (да хоть 10), видео-файл будет писаться в самый глубокий фолдер. Ты утверждаешь, что это хоть как-то измеримо помешает производительности ввода-вывода ?

Да, можешь попробовать. Особо чувствительно, когда ты на пределе пропускной способности диска. Я уже проходил. После чего, собственно, стал интересоваться.

DSB> Нет, подменять предмет дискуссии не надо. Хочешь - открывай другую.

Дык, терминология в книжках, MSDN и в коде иногда немного разнится. Но спорить не буду — я подписал NDA и внутренностей выкладывать не буду — по голове настучат, выгонят с работы и ещё оштрафуют.

DSB> Рассматривает вообще-то. И рассматривает "особо" - есть отдельная глава. Вообще спор не о кэше. Но если я что-то путаю, то знающему человеку нетрудно будет конкретно сказать что именно.

Ы? Посмотри первое высказывание, на которое ты наехал — не хватит памяти под кэш.
А про кэши — что, с того, что глава есть? Ты посмотри, как и когда память под кэши выделяется и освобождается. И почему программа может вытеснить кэш. Ты в ситуацию попадал, когда система жалуется, что мало памяти, даже виртуальной? Посмотри, сколько там на кэш в этот момент выделено.

Mishka> Не верно. Время обновляется не во время закрытия файла, а во время модификации. Файл может быть открыт, изменение произведено, а файл всё ещё не закрыт. Дата обновления должна уже быть новая.
Хм, проверим...

DSB>> Зачем? Чтобы в ответ услышать "Копай дальше"? У меня нет столько свободного времени. Если есть конкретное возражение, то говори.
Mishka> Дык, подумай. Я тебе уже много говорить не буду. Кеширование с работой ФС соотноястяся слабо — ФС должна работать и без кеширования. Подробностей, пардон, не будет. NDA надо мной висит и будет висеть, пока я в этой компании работаю.
NDA (подписка о неразглашении?) тебе мешает упомянуть хоть одну структуру внутри NTFS? А вот ты мне книжку тётки советовал - цитируй из неё или и это нельзя? Или суть нашего спора затрагивает самые сокровенные тайны Microsoft, на которые можно лишь туманно намекать?

DSB>> Если размер файла будет сравним с размером тома, то велика вероятность, что он тоже будет записан не неприрывной цепочкой LCN. Почему? 1. $MFTMirr находится в середине тома и делит его пополам. 2. Фйлы протоколирования NTFS и прочие метаданные тоже могут разместиться неудачно (уж не знаю, где они стандартно размещаются физически).
Mishka> Зеркало можно и смещать. Ну и протоколирование у тебя не полное.
Ну а кто кричал, что файл палюбому будет не дефрагментирован. Кто предлагал мне доказать обратное? Я доказал. В ответ получаю нечто.... не похожее на радость познания.

DSB>> Давай-ка я ещё раз уточню предмет спора. Имеем чистый том NTFS c кластером в 64K. Я создаю на нём пару пустых вложенных фолдеров (да хоть 10), видео-файл будет писаться в самый глубокий фолдер. Ты утверждаешь, что это хоть как-то измеримо помешает производительности ввода-вывода ?
Mishka> Да, можешь попробовать. Особо чувствительно, когда ты на пределе пропускной способности диска. Я уже проходил. После чего, собственно, стал интересоваться.
Мишка, ну ты как вошь на гребешке. Пока я из тебя выбил только 2 аргумента почему ты так считаешь:
1. Во время модификации видеофайла ОС будет постоянно обновлять дату модификации родительского фолдера (или всех вложенных фолдеров?)
2. Вложенные фолдеры (даже пустые) фрагментируют пространство тома.
Ничего не пропустил?

DSB> NDA (подписка о неразглашении?) тебе мешает упомянуть хоть одну структуру внутри NTFS? А вот ты мне книжку тётки советовал - цитируй из неё или и это нельзя? Или суть нашего спора затрагивает самые сокровенные тайны Microsoft, на которые можно лишь туманно намекать?

Подписка не даёт мне прав говорить в терминах исходного кода. Там где стоят указатели типа void и массивы из байтов.

DSB> Ну а кто кричал, что файл палюбому будет не дефрагментирован. Кто предлагал мне доказать обратное? Я доказал. В ответ получаю нечто.... не похожее на радость познания.

Я же сказал, что их можно сдвинуть и сделать по концам. Ну и с уровнем логирования можно играться. Только это зависит от версии.

DSB> Мишка, ну ты как вошь на гребешке. Пока я из тебя выбил только 2 аргумента почему ты так считаешь:

Я знаю, а не считаю.

DSB> 1. Во время модификации видеофайла ОС будет постоянно обновлять дату модификации родительского фолдера (или всех вложенных фолдеров?)

Файла. Возможно и кое-что для фолдера.

DSB> 2. Вложенные фолдеры (даже пустые) фрагментируют пространство тома.

Не пустые, а с файлами. Поскольку фолдеры сами файлы.

DSB> Ничего не пропустил?
Пропустил. Кеширование.

Mishka> Подписка не даёт мне прав говорить в терминах исходного кода. Там где стоят указатели типа void и массивы из байтов.
Ну и отлично, тем более, что в этом нет никакой необходимости.

DSB>> Ну а кто кричал, что файл палюбому будет не дефрагментирован. Кто предлагал мне доказать обратное? Я доказал. В ответ получаю нечто.... не похожее на радость познания.
Mishka> Я же сказал, что их можно сдвинуть и сделать по концам. Ну и с уровнем логирования можно играться. Только это зависит от версии.
Ты глянь, всё у тебя можно сдвинуть и настроить, кроме ... несчастных пустых фолдеров Надо взять на заметку этот способ вести дискуссию )

DSB>> Мишка, ну ты как вошь на гребешке. Пока я из тебя выбил только 2 аргумента почему ты так считаешь:
Mishka> Я знаю, а не считаю.
DSB>> 1. Во время модификации видеофайла ОС будет постоянно обновлять дату модификации родительского фолдера (или всех вложенных фолдеров?)
Mishka> Файла. Возможно и кое-что для фолдера.
Файла? ) Так ведь нет никакой разницы, где лежит файл в корне или не в корне. В любом случае обновляется запись в MFT ЭТОГО файла. Дата модификации - резидентный атрибут MFT !
Вот на что ты мне действительно глаза открыл, так это на Date Accessed атрибут фолдеров, но поскольку их можно отключить, то это не считается )))

HKLM\System\CurrentControlSet\Control\FileSystem.
Create a new DWORD value called 'NtfsDisableLastAccessUpdate' and set the value to '1'

DSB>> 2. Вложенные фолдеры (даже пустые) фрагментируют пространство тома.
Mishka> Не пустые, а с файлами. Поскольку фолдеры сами файлы.
А я специально уточнял 2 раза - ты подтверждал, что да, - проблема возникнет и с пустыми фолдерами тоже.

DSB>> Ничего не пропустил?
Mishka> Пропустил. Кеширование.
Скажи ещё раз pls. В чём тут проблема.