Вопрос архитекторам

[Иосиф]

А зачем иметь тысячу файлов?
Создай один sparse файл, длиной в 1000Gb, где каждому клиенту отведено 1Gb виртуального дискового пространства. Понятно, что область, принадлежащая каждому клиенту будет высчитываться по смещению относительно начала файла. Ты избегаешь замусоривания MFT и сохраняешь все прелести непосредственного чтения с диска вместо обращения к серверу базы.

Я понял идею. С трудом себе представляю, как такой файл будет бэкапиться. Если скорость записи на ленту 0,5 Гб/мин и файл на 200 Гб - 400 минут нужно, при этом почти уверен, что для записи файл нужно будет блокировать (иначе непонятно, что в нем есть, а чего нет). Мы не можем себе позволить останов на 7 часов. Есть обходные пути?
Кстати, МФТ замусорена системными файлами настолько, что от моей тысячи уже ничего не изменится

Иосиф

[Yocto]

Возможно, ты не понял.
Sparse файл - это файл, длина которого не обязательно равна занимаемому на диске месту.
Можно создать файл длиной в 1Tb, который на диске будет занимать 1Kb. Возможность создавать такие файлы - одна из редко используемых но очень интересных фич для NTFS.
Это можно объяснить аналогией с виртуальной памятью, когды ты запрашиваешь (и получаешь) кусок в 1Gb, даже не смотря на то, что у тебя реально столько нету. Просто это будет означать, что тебе выделен виртуальный кусок пространства, не обязательно отраженный на реальную память, которая будет подгружаться диспетчером памяти по мере надобности.

[Yocto]

Кстати, МФТ замусорена системными файлами настолько, что от моей тысячи уже ничего не изменится

Самые нужные системные файлы всегда загружены в память и для их загрузки скан MFT не требуется. Они действительно отъедают дисковое пространство и сказываются на скорости поиска в индексе при запросе на открытие любого файла, но это - систематическая погрешность, которую можно учесть и с которой приходится мириться.

[Иосиф]

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

Дело в том, что у меня реально будет 200+ Гб данных. Есть возможность мапить сразу много физических файлов в один спарс? Если нет, то моё замечание насчёт бэкапа в силе.

Относительно МФТ: все файлы будут открываться один раз, хэндлы будут валиться в лист и юзаться когда надо, только локи на кусочки ставиться будут. Так что скан опять-таки не понадобится (если моя идея реализуема).

Иосиф

[Yocto]

Дело в том, что у меня реально будет 200+ Гб данных. Есть возможность мапить сразу много физических файлов в один спарс? Если нет, то моё замечание насчёт бэкапа в силе.

Относительно МФТ: все файлы будут открываться один раз, хэндлы будут валиться в лист и юзаться когда надо, только локи на кусочки ставиться будут. Так что скан опять-таки не понадобится (если моя идея реализуема).

Иосиф

Ну, если проблема со скоростью открытия файля тебя не заботит, так в чём тогда трудности? Тогда тебе и простый файлы пойдут, sparse не нужен.

Sparse хорош тем, что в некоторых вариантах можно избежать блокировок. Скажем, для каждого клиента новую порцию данных всё время пишешь в конец отведенной данному пользователю области, предыдуший неактуальный фрагмент можно сбрасывать на ленту с последующим обнулением (реальным освобождением дискового пространства). Поскольку эти процессы в файле не пересекаются - блокировка не требуется.
Остальное зависит от твоих условий, как то: частота backups, скорость поступления данных, требуемый отклик системы и пр.

[Иосиф]

Ну, если проблема со скоростью открытия файля тебя не заботит, так в чём тогда трудности? Тогда тебе и простый файлы пойдут, sparse не нужен.

Я простые и пользую пока Мне бы с ними разобраться для начала. Но скорость открытия меня волнует, именно поэтому я открываю все файлы лишь один раз. Займёт это 3 секунды (не займёт, я для примера) - фигня. Просто 200К файлов так не откроешь, мне кажется, а 1К - должно быть можно.

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

Это интересно. Я вначале тогда почитаю об этом спарсе, иначе слишком много дурных вопросов будет. Спасибо.

Иосиф