Страница 3 из 3
Добавлено: 08 окт 2003, 06:55
Иосиф
Yocto писал(а):А зачем иметь тысячу файлов?
Создай один sparse файл, длиной в 1000Gb, где каждому клиенту отведено 1Gb виртуального дискового пространства. Понятно, что область, принадлежащая каждому клиенту будет высчитываться по смещению относительно начала файла. Ты избегаешь замусоривания MFT и сохраняешь все прелести непосредственного чтения с диска вместо обращения к серверу базы.
Я понял идею. С трудом себе представляю, как такой файл будет бэкапиться. Если скорость записи на ленту 0,5 Гб/мин и файл на 200 Гб - 400 минут нужно, при этом почти уверен, что для записи файл нужно будет блокировать (иначе непонятно, что в нем есть, а чего нет). Мы не можем себе позволить останов на 7 часов. Есть обходные пути?
Кстати, МФТ замусорена системными файлами настолько, что от моей тысячи уже ничего не изменится
Иосиф
Добавлено: 08 окт 2003, 07:13
Yocto
Возможно, ты не понял.
Sparse файл - это файл, длина которого не обязательно равна занимаемому на диске месту.
Можно создать файл длиной в 1Tb, который на диске будет занимать 1Kb. Возможность создавать такие файлы - одна из редко используемых но очень интересных фич для NTFS.
Это можно объяснить аналогией с виртуальной памятью, когды ты запрашиваешь (и получаешь) кусок в 1Gb, даже не смотря на то, что у тебя реально столько нету. Просто это будет означать, что тебе выделен виртуальный кусок пространства, не обязательно отраженный на реальную память, которая будет подгружаться диспетчером памяти по мере надобности.
Добавлено: 08 окт 2003, 07:17
Yocto
Иосиф писал(а):
Кстати, МФТ замусорена системными файлами настолько, что от моей тысячи уже ничего не изменится
Самые нужные системные файлы всегда загружены в память и для их загрузки скан MFT не требуется. Они действительно отъедают дисковое пространство и сказываются на скорости поиска в индексе при запросе на открытие любого файла, но это - систематическая погрешность, которую можно учесть и с которой приходится мириться.
Добавлено: 08 окт 2003, 07:26
Иосиф
Yocto писал(а):Возможно, ты не понял.
Sparse файл - это файл, длина которого не обязательно равна занимаемому на диске месту.
Дело в том, что у меня реально будет 200+ Гб данных. Есть возможность мапить сразу много физических файлов в один спарс? Если нет, то моё замечание насчёт бэкапа в силе.
Относительно МФТ: все файлы будут открываться один раз, хэндлы будут валиться в лист и юзаться когда надо, только локи на кусочки ставиться будут. Так что скан опять-таки не понадобится (если моя идея реализуема).
Иосиф
Добавлено: 08 окт 2003, 07:37
Yocto
Иосиф писал(а):
Дело в том, что у меня реально будет 200+ Гб данных. Есть возможность мапить сразу много физических файлов в один спарс? Если нет, то моё замечание насчёт бэкапа в силе.
Относительно МФТ: все файлы будут открываться один раз, хэндлы будут валиться в лист и юзаться когда надо, только локи на кусочки ставиться будут. Так что скан опять-таки не понадобится (если моя идея реализуема).
Иосиф
Ну, если проблема со скоростью открытия файля тебя не заботит, так в чём тогда трудности? Тогда тебе и простый файлы пойдут, sparse не нужен.
Sparse хорош тем, что в некоторых вариантах можно избежать блокировок. Скажем, для каждого клиента новую порцию данных всё время пишешь в конец отведенной данному пользователю области, предыдуший неактуальный фрагмент можно сбрасывать на ленту с последующим обнулением (реальным освобождением дискового пространства). Поскольку эти процессы в файле не пересекаются - блокировка не требуется.
Остальное зависит от твоих условий, как то: частота backups, скорость поступления данных, требуемый отклик системы и пр.
Добавлено: 08 окт 2003, 07:48
Иосиф
Yocto писал(а):
Ну, если проблема со скоростью открытия файля тебя не заботит, так в чём тогда трудности? Тогда тебе и простый файлы пойдут, sparse не нужен.
Я простые и пользую пока

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