rs
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
DenZzz
Цитата: Цитата:чтобы обнаружить факт наступления рассинхронизации - нужно ВЫПОЛНЯТЬ этот контроль, т.е. читать время от времени (как часто?) ВСЕ(!) файлы в кэше, на предмет сверки с индексом...
Не обязательно! Когда рассинхронизация выявится, тогда и будем проверять индекс. А выявится она, когда HC не найдет в кэше файл, который есть у него в индексе - т.е. практически при первой загрузке этого сайта (хоста) |
ты не понял - сама по себе рассинхронизация не выявится.. ты её должен СПЕЦИАЛЬНО выявлять, т.е. ПРЕДПРИНИМАТЬ некие действия (затратив ресурсы - процессорные, дисковые, которые твы кстати и хочешь сэкономить, а вынуждет тратить) - ведь не найдя файла в индексе (а в кэше на самом деле файл есть), HC понятия не имеет, что не нашёл файл в кэше лишь по причине кривизны индекса - он (HC) искренне считает, что файла нет в кэше, хотя его нет только в индексе... для того чтобы ЗАПОДОЗРИТЬ рассинхронизацию нужны предположения о рассинхронизации (откуда они возьмутся?) и ДЕЙСТВИЯ по ОБНАРУЖЕНИЮ рассинхрона... можно конечно что-то типа планировщика сделать, запусакющего тест синхронности индекса и кэша... но как-то это всё архитектурной косолапостью системы попахивает... подпорки на подпорках...
Цитата:| Ты нет, а вот SAI666 даже предлагал изменить порядок списков и добавить второй ЧС для ускорения работы с диском! С индексом всего этого "добра" не понадобится! |
ты упускаешь 1)существенно более весомые затраты на ПОДДЕРЖАНИЕ синхронизации [см. в моём абзаце выше] и 2)достаточно высокую вероятность попасть в рассинхронизированное состояние индекса в интеравалах между процедурами контроля синхронизации. и поскольку, как ты сам согласился, потеря атрибутов индекса необратима (из файловкэша их взять уже нельзя) - то имеем ещё к первым двум пунктам ещё один смачный довесок минусов - 3)часть файлов в кэше могут иметь доп. атрибуты (не имели проблем с индексами), а другие в этом же кэше уже не имеют дп. атрибутов (потеряли индекс и не смогли их восстановить по кэшу) - "клочакстое" наполнение атрибутами файлов кэша.
всё это СЛИШКОМ серьёзные минусы, чтобы закладывать их в качестве архитектурного решения.
НИ ОДИН из ЭТИХ минусов не свойствен потокам в файлах кэша по определению... - следовательно для решения этих проблем можно ВООБЩЕ НИЧЕГО предпринимать - этих проблем просто НЕТ.
Цитата:| Угу, и двойная нагрузка на диск - это вовсе не нагрузка.. |
есть проги, типа filemon от sysinternals, кажется... - можешь посмотреть что ежесекундно происходит с диском - ты просто ужаснёшься - и своп и реестр и антивирус и... - в общем на фоне этого дискового общеситсемного беспредела всевозможных программ и програмулечек, пишущих и читающих диск - лишний один поток (крохотный поточек) на файл в кэше - это просто смешно... это даже не проценты, это доли процентов от объёма общесистемных файловых операций в течение того же времени, что и доступ к файлу кэша
Цитата: Что вы опять заладили здесь про потоки... Mai62 сказал: "ПОТОКОВ НЕ БУДЕТ"!!!
|
такое впечатление, что ты услышал то, что тебе приятнее было бы слышать
он сказал лишь, что не хочет сейчас вступать в обсуждение... вероятно, не готов занять любую из позиций и что ntfs-потоки ему не очень нравятся... вполне разумно, в общем-то... а с чего ты вязл, что он под действием аргументов не изменит мнения c течением времени?
Цитата:| А время и практика покажет, кто был прав!!! Думаю, очень быстро покажет... |
чудится мне, что решать будет всё же НЕ ВРЕМЯ, а ЛЮДИ с течением времени - разница всё ж есть...
а чтобы эти люди решили с течением времени - требуется ОБСУЖДЕНИЕ... из ничего (без обсуждения) архитектура не родится
unreal666
Цитата:| Пускай сделает API и будут потоки. |
вот именно
|
