Давно уже раздражает, что винда в гостевых VM не кэширует файлы, доступные через Shared Folders — и под VMware, и под VirtualBox файлы читаются с хоста при каждом обращении, и ускоряет чтение только кэш хоста, но обмен через сетевые протоколы очень сильно тормозит чтение мелких файлов.
Гуглил на тему кэширования сетевых файлов, но пишут в основном о том, как включить кэширование в SMB, и только на той стороне, которая предоставляет ресурсы, но в данном случае полноценного SMB-шаринга нет, только эмуляция.
Представители VMware когда-то писали, что файлы должны кэшироваться на стороне гостя, но я этого не вижу — в Process Monitor видно, что каждое чтение файла в гостевой системе вызывает его чтение на хосте. То ли еще тогда не доделали, то ли потом поломали.
Есть ли возможность заставить кэшировать файлы именно гостевую винду?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Давно уже раздражает, что винда в гостевых VM не кэширует файлы, доступные через Shared Folders — и под VMware, и под VirtualBox файлы читаются с хоста при каждом обращении, и ускоряет чтение только кэш хоста, но обмен через сетевые протоколы очень сильно тормозит чтение мелких файлов.
ЕМ>Есть ли возможность заставить кэшировать файлы именно гостевую винду?
Только через полноценную SMB шару, а лучше NFS.
С большими файлами скорость одинаковая, а на файлах до мегабайта NFS "уделывает" SMB в разы. Локально для VM в VMware Workstation, через виртуальные сетевые карты скорость доступа ограничивается скоростью хостового диска, по физической сети скоростью сетевого интерфейса.
Все проблемы от жадности и глупости
Re[2]: Как заставить гостевую винду кэшировать Shared Folders?
Здравствуйте, Stanislaw K, Вы писали:
SK>Только через полноценную SMB шару
Вот странно совсем. По идее, на стороне ресурса управление кэшированием должно работать на уровне предложения/совета, но никак не принудительного задания режима, которое логично иметь как раз на стороне клиента.
Откуда пошла эта извращенность?
Re[3]: Как заставить гостевую винду кэшировать Shared Folders?
Здравствуйте, Евгений Музыченко, Вы писали:
SK>>Только через полноценную SMB шару
ЕМ>Вот странно совсем. По идее, на стороне ресурса управление кэшированием должно работать на уровне предложения/совета, но никак не принудительного задания режима, которое логично иметь как раз на стороне клиента.
Это же не глобальный интернет с низкой скоростью и покилобайтной оплатой трафика а локальная сеть. Тут логичнее совсем убрать кэширование с сетевого уровня а при необходимости реализовать его прикладным ПО.
ЕМ>Откуда пошла эта извращенность?
От безопасности, в первую очередь. На сервере могут лежать весьма конфиденциальные данные, только владелец файлов (сервер) решает можно ли делать локальную копию и на сколько она должна быть актуальной.
С SMB кэшом часто встречаются ситуации, когда файл в локальном кэше устарел на часы или вообще удален на сервере. Прикладное ПО клиента, полагаясь на сеть, продолжает видеть некорректную версию.
Все проблемы от жадности и глупости
Re[4]: Как заставить гостевую винду кэшировать Shared Folders?
Здравствуйте, Stanislaw K, Вы писали:
SK>Тут логичнее совсем убрать кэширование с сетевого уровня а при необходимости реализовать его прикладным ПО.
Э-э-э... То ли я Вас не понял, то ли Вы меня. Если кэширование кода/данных в отдельно взятом компьютере логично реализовать максимально близко к АЛУ процессора, то с чего вдруг кэширование сетевых ресурсов в локальной сети стало логичным реализовать вдалеке от клиентского компьютера, потребляющего эти ресурсы?
И откуда может взяться "необходимость" реализовать кэширование в прикладом ПО, когда это уже давно стандартная функция любой ОС?
SK>На сервере могут лежать весьма конфиденциальные данные, только владелец файлов (сервер) решает можно ли делать локальную копию
Тут я вообще перестал понимать, о чем речь. В любой адекватной системе безопасности, если сервер однажды принял решение отдать данные, то эти данные автоматически считаются ушедшими из его зоны ответственности. Соответственно, об их сохранности должны заботиться внешние слои защиты, и попытки как-то управлять кэшированием будут не более, чем уродливым костылем, добавляющим сложности, но не добавляющим безопасности.
А если клиентский компьютер однажды получил с сервера данные, то их кэширование в системе будет одним из последних факторов, который мог бы способствовать утечке.
SK>и на сколько она должна быть актуальной.
Этот вопрос решается другими средствами — запросом соответствия, установкой времени обновления и т.п. В той же паре "сервер-браузер" это реализовано, и никак не мешает браузеру и кэшировать ресурсы, и управлять режимами кэширования на своей стороне. Сервер может давать лишь рекомендации, но никак не диктовать правила.
SK>С SMB кэшом часто встречаются ситуации, когда файл в локальном кэше устарел на часы или вообще удален на сервере. Прикладное ПО клиента, полагаясь на сеть, продолжает видеть некорректную версию.
Так именно для исключения подобных ситуаций и применяется управление кэшированием на стороне клиента, чтоб можно было настроить различные режимы и правила. Если в винде этого нет, то я даже не знаю, как правильнее описать степень убожества такой конструкции.
А в линуксах такое управление есть?
Re[5]: Как заставить гостевую винду кэшировать Shared Folders?
Здравствуйте, Евгений Музыченко, Вы писали:
SK>>Тут логичнее совсем убрать кэширование с сетевого уровня а при необходимости реализовать его прикладным ПО.
ЕМ>Э-э-э... То ли я Вас не понял, то ли Вы меня. Если кэширование кода/данных в отдельно взятом компьютере логично реализовать максимально близко к АЛУ процессора, то с чего вдруг кэширование сетевых ресурсов в локальной сети стало логичным реализовать вдалеке от клиентского компьютера, потребляющего эти ресурсы?
Я имел в виду — отказаться от кэширования (на сетевом уровне), поднять его (ближе к CPU) на уровень приложения. Как странички сайтов кэшируются не tcp/ip стеком (на низком уровне провода) а самими прикладным ПО браузером.
ЕМ>И откуда может взяться "необходимость" реализовать кэширование в прикладом ПО, когда это уже давно стандартная функция любой ОС?
Разные кэши.
SK>>На сервере могут лежать весьма конфиденциальные данные, только владелец файлов (сервер) решает можно ли делать локальную копию
ЕМ>Тут я вообще перестал понимать, о чем речь. В любой адекватной системе безопасности, если сервер однажды принял решение отдать данные, то эти данные автоматически считаются ушедшими из его зоны ответственности.
В персональных компьютерах систему безопасности строили военный, спец.службист и хипстер-анархист. у каждого свой взгляд на архитектуру безопасности. в результате получилась вот такая уродливая система.
ЕМ>Соответственно, об их сохранности должны заботиться внешние слои защиты, и попытки как-то управлять кэшированием будут не более, чем уродливым костылем, добавляющим сложности, но не добавляющим безопасности.
Клиентский комп может находится в защищенной доверенной локальной сети, где каждый ip пкет зашифрован и подписан, но при этом быть не совсем доверенным терминалом общего доступа — сейчас за ним условный доставщик пиццы пропуск отмечает, а минуту назад директор агентства правительственные секреты читал.
ЕМ>А если клиентский компьютер однажды получил с сервера данные, то их кэширование в системе будет одним из последних факторов, который мог бы способствовать утечке.
Кто знает, какие уязвимости могут найтись в ближайшие 5 минут..
SK>>и на сколько она должна быть актуальной.
ЕМ>Этот вопрос решается другими средствами — запросом соответствия, установкой времени обновления и т.п.
Паразитным трафиком. Для мелких файлов он может оказаться на порядок бОльшим самого файла.
ЕМ>В той же паре "сервер-браузер" это реализовано, и никак не мешает браузеру и кэшировать ресурсы, и управлять режимами кэширования на своей стороне. Сервер может давать лишь рекомендации, но никак не диктовать правила.
Браузер прикладное ПО, несколько выше сетевого стека.
SK>>С SMB кэшом часто встречаются ситуации, когда файл в локальном кэше устарел на часы или вообще удален на сервере. Прикладное ПО клиента, полагаясь на сеть, продолжает видеть некорректную версию.
ЕМ>Так именно для исключения подобных ситуаций и применяется управление кэшированием на стороне клиента, чтоб можно было настроить различные режимы и правила. Если в винде этого нет, то я даже не знаю, как правильнее описать степень убожества такой конструкции.
ЕМ>А в линуксах такое управление есть?
Операционка не имеет значения, эта "беда" заложена в SMB.
Все проблемы от жадности и глупости
Re[6]: Как заставить гостевую винду кэшировать Shared Folders?
Здравствуйте, Stanislaw K, Вы писали:
SK>отказаться от кэширования (на сетевом уровне)
Что за "сетевой уровень" кэширования, где именно он находится, и как работает?
SK>поднять его (ближе к CPU) на уровень приложения
Зачем поднимать его на уровень приложения, когда в любой современной ОС есть системное кэширование на уровне файлов?
SK>Как странички сайтов кэшируются не tcp/ip стеком (на низком уровне провода) а самими прикладным ПО браузером.
Для страничек тупо нет другой возможности кэширования. На уровне TCP/IP данные кэшировать объективно невозможно, ибо там неизвестна сама природа этих данных. Вид, пригодный для кэширования, они приобретают только на "сетевом уровне" браузера, когда он определяет, какие элементы потока TCP должны объединяться в страницу. В ситуации с сетевыми файлами/каталогами этому уровню браузера примерно соответствует файловый менеджер клиентской ОС, а приложение — "отображающему" уровню браузера. Какой смысл тащить в каждое приложение то, что однажды уже реализовано в общем файловом менеджере?
ЕМ>>откуда может взяться "необходимость" реализовать кэширование в прикладом ПО, когда это уже давно стандартная функция любой ОС?
SK>Разные кэши.
Сколько Вы знаете приложений, работающих с "просто файлами" (не СУБД), которые сами организуют кэширование этих файлов?
SK>В персональных компьютерах систему безопасности строили военный, спец.службист и хипстер-анархист. у каждого свой взгляд на архитектуру безопасности. в результате получилась вот такая уродливая система.
Мне одному кажется, что здесь Вы пытаетесь замаскировать заблуждения абстрактными рассуждениями?
SK>Клиентский комп может находится в защищенной доверенной локальной сети
Ключевое слово — "может". В подавляющем большинстве случаев — не находится. Кто бы стал закладываться на относительно редкие случаи при построении общей конфигурации? Особенно при том, что описываемые Вами меры отнюдь не решают проблемы безопасности.
ЕМ>>Этот вопрос решается другими средствами — запросом соответствия, установкой времени обновления и т.п.
SK>Паразитным трафиком. Для мелких файлов он может оказаться на порядок бОльшим самого файла.
Как будто в ОС и сетях мало паразитного трафика. Проблема не в нем самом, а в наличии средств управления им.
ЕМ>>В той же паре "сервер-браузер" это реализовано, и никак не мешает браузеру и кэшировать ресурсы, и управлять режимами кэширования на своей стороне. Сервер может давать лишь рекомендации, но никак не диктовать правила.
SK>Браузер прикладное ПО, несколько выше сетевого стека.
Да какая разница? Если сервер однажды отдал браузеру конфиденциальные данные, он уже не вправе рассчитывать на сохранение их конфиденциальности. Разумеется, это справедливо лишь для грамотно построенной системы безопасности — к системам с иллюзией безопасности это не относится.
SK>Операционка не имеет значения, эта "беда" заложена в SMB.
Я по-прежнему в упор не понимаю, что может технически помешать любой операционке кэшировать сетевые файлы на своей стороне для ускорения работы с ними (ну, кроме тупого упрямства разработчиков). Если дать пользователю возможность управлять сроками жизни кэшированных копий, он чаще всего сможет подобрать такие параметры, при которых работа идет значительно быстрее, и не возникает проблем с актуальностью.
Re[7]: Как заставить гостевую винду кэшировать Shared Folders?
Здравствуйте, Евгений Музыченко, Вы писали: SK>>отказаться от кэширования (на сетевом уровне) ЕМ>Что за "сетевой уровень" кэширования, где именно он находится, и как работает?
В данном случае от SMB клиента, включая его, и ниже.
SK>>Как странички сайтов кэшируются не tcp/ip стеком (на низком уровне провода) а самими прикладным ПО браузером. ЕМ>Для страничек тупо нет другой возможности кэширования. На уровне TCP/IP данные кэшировать объективно невозможно, ибо там неизвестна сама природа этих данных. Вид, пригодный для кэширования, они приобретают только на "сетевом уровне" браузера,
Браузер работает на прикладном (osi 7), не опускаясь даже до представления (osi 6). ЕМ>когда он определяет, какие элементы потока TCP должны объединяться в страницу. В ситуации с сетевыми файлами/каталогами этому уровню браузера примерно соответствует файловый менеджер клиентской ОС, а приложение — "отображающему" уровню браузера. Какой смысл тащить в каждое приложение то, что однажды уже реализовано в общем файловом менеджере? ЕМ>>>откуда может взяться "необходимость" реализовать кэширование в прикладом ПО, когда это уже давно стандартная функция любой ОС? SK>>Разные кэши. ЕМ>Сколько Вы знаете приложений, работающих с "просто файлами" (не СУБД),
СУБД это частный случай файловой системы, отличие только в пути. на диске файл "лежит" c:\windows\readme.txt в СУБД файл "лежит" в "select * from somewhere where x=y limit 1" ЕМ>которые сами организуют кэширование этих файлов?
notepad не подойдет? тогда тот же FAR. SK>>В персональных компьютерах систему безопасности строили военный, спец.службист и хипстер-анархист. у каждого свой взгляд на архитектуру безопасности. в результате получилась вот такая уродливая система. ЕМ>Мне одному кажется, что здесь Вы пытаетесь замаскировать заблуждения абстрактными рассуждениями?
Кажется. Это был "вольный экскурс в историю". SK>>Клиентский комп может находится в защищенной доверенной локальной сети ЕМ>Ключевое слово — "может". В подавляющем большинстве случаев — не находится.
В подавляющем большинстве случаев именно там (корпоративная локальная сеть) и находится. ЕМ>Кто бы стал закладываться на относительно редкие случаи при построении общей конфигурации?
Тот, кто в 70х не предполагал распространения персональных(!) компьютеров в каждый дом, а тем более количестве больше одного. ЕМ>>>Этот вопрос решается другими средствами — запросом соответствия, установкой времени обновления и т.п. SK>>Паразитным трафиком. Для мелких файлов он может оказаться на порядок бОльшим самого файла. ЕМ>Как будто в ОС и сетях мало паразитного трафика. Проблема не в нем самом, а в наличии средств управления им.
SMB сеансовый протокол. на каждый чих "открыть сеанс, авторизоваться, отправить запрос, получить данные, закрыть сеанс." "открыть сеанс, авторизоваться, отправить запрос, получить данные, закрыть сеанс." "открыть сеанс, авторизоваться...."
На маленьких файлах служебный трафик связанный с файлом может превышать размер файла в разы. С кэшированием служебный трафик (каждые N времени перезапрашивать актуальность) быстро превращается в паразитный (и плюс нагрузка на CPU сервера). SK>>Операционка не имеет значения, эта "беда" заложена в SMB. ЕМ>Я по-прежнему в упор не понимаю, что может технически помешать любой операционке кэшировать сетевые файлы на своей стороне для ускорения работы с ними (ну, кроме тупого упрямства разработчиков). Если дать пользователю возможность управлять сроками жизни кэшированных копий, он чаще всего сможет подобрать такие параметры, при которых работа идет значительно быстрее, и не возникает проблем с актуальностью.
Если за 40 лет которые протокол использовался и развивался (корпорациями зарабатывающими на нём деньги), в нем добавили многое и исправили многое, а кэширование "не сделали", наверное этому есть причины.
Все проблемы от жадности и глупости
Re[8]: Как заставить гостевую винду кэшировать Shared Folders?
Я при всем желании не могу представить, как можно было бы организовать кэширование в стеке OSI на любом из уровней ниже прикладного — там нет никаких самостоятельных, законченных, единиц данных — только кадры, фрагменты, потоки и прочее. Да и на прикладном они тоже не всегда есть. Если Вы имеете такое представление — поделитесь, реально любопытно. SK>Браузер работает на прикладном (osi 7), не опускаясь даже до представления (osi 6).
Теперь у меня возникло подозрение, что Вы отождествляете прикладной уровень OSI с прикладным ПО, что в общем случае не так, а в обсуждаемом случае (отображение файловой системы ОС на ресурсы SMB) — совершенно не так. SK>СУБД это частный случай файловой системы, отличие только в пути. на диске файл "лежит" c:\windows\readme.txt в СУБД файл "лежит" в "select * from somewhere where x=y limit 1"
Ага, а вещественное число — частный случай комплексного, только знание об этом мало помогает решению практических задач, особенно в плане оптимизации вычислений, которую чаще приходится подгонять под задачу, а не под теорию.
Может, хватит уже абстрактно-философских построений? Иначе Вы рискуете полностью потерять связь с исходным вопросом. ЕМ>>которые сами организуют кэширование этих файлов? SK>notepad не подойдет? тогда тот же FAR.
Каким образом (а главное — для чего) notepad или FAR самостоятельно организуют кэширование файлов? SK>Это был "вольный экскурс в историю".
От того, что по существу сказать нечего, но высказаться очень хочется? SK>На маленьких файлах служебный трафик связанный с файлом может превышать размер файла в разы.
Да и ради бога. Те, кому он мешает, могли бы установить периодичность проверки актуальности, или вовсе отключить кэширование. А меня бы полностью устроила периодичность хоть раз в час, с возможностью принудительной ручной синхронизации. Уверен, что таких найдется еще минимум несколько миллионов. SK>С кэшированием служебный трафик (каждые N времени перезапрашивать актуальность) быстро превращается в паразитный (и плюс нагрузка на CPU сервера).
Я бы понял, если б Вы все это излагали хотя бы лет двадцать назад, а не сейчас, когда подобные изречения выглядят откровенно смешно на фоне гигабайт чисто паразитного трафика, и миллионов чисто паразитных операций CPU в секунду, что считается вполне в порядке вещей. SK>Если за 40 лет которые протокол использовался и развивался (корпорациями зарабатывающими на нём деньги), в нем добавили многое и исправили многое, а кэширование "не сделали"
Да что Вы уперлись в протокол? В обсуждаемом вопросе протокол вообще не актуален — он полностью лежит под файловым менеджером любой ОС, которая его использует. Для использования разумного кэширования нет ни малейшей нужды в модификации протокола.
Re[3]: Как заставить гостевую винду кэшировать Shared Folders?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот странно совсем. По идее, на стороне ресурса управление кэшированием должно работать на уровне предложения/совета, но никак не принудительного задания режима, которое логично иметь как раз на стороне клиента.
ЕМ>Откуда пошла эта извращенность?
А в венде кто кеширует-то, VFS или каждая файловая система сама за себя?
Re[4]: Как заставить гостевую винду кэшировать Shared Folders?
Здравствуйте, Pzz, Вы писали:
Pzz>А в венде кто кеширует-то, VFS или каждая файловая система сама за себя?
Кэширует общий Cache Manager, работающий в связке с Memory Manager. Отображает блоки файлов на страницы памяти — так же, как это делается в Mapped File Views. Судя по тому, что многие программы работают с файлами именно через отображение в память, а не через чтение/запись, и при этом успешно работают как с сетевыми файлами, так и с Shared Folders, там универсальные интерфейсы и протоколы.
Сейчас вдруг вспомнил, что под VMware, если в гостевой системе читать/писать файлы в Shared Folders в стандартном режиме (с буферизацией), то VM часто держит хостовый файл открытым какое-то время после его закрытия в гостевой системе. Мне для этого даже пришлось сваять утилиту, копирующую файлы с отключенной буферизацией. Это очень похоже на работу кэша, но тогда непонятно, почему повторные чтения файлов в гостевой системе вызывают их повторные чтения в хостовой. Такое впечатление, что в этой схеме что-то поломано.
Re: Как заставить гостевую винду кэшировать Shared Folders?
ЕМ>Представители VMware когда-то писали, что файлы должны кэшироваться на стороне гостя, но я этого не вижу — в Process Monitor видно, что каждое чтение файла в гостевой системе вызывает его чтение на хосте. То ли еще тогда не доделали, то ли потом поломали.
В Process Monitor, запущенный на сервере ?
Тут такой момент. Локальные файлы под контролем Windows. Если иной процесс их изменит, Windows изменит и кеш.
А с сетевыми файлами кеширование возможно не всегда
ЕМ>Я при всем желании не могу представить, как можно было бы организовать кэширование в стеке OSI на любом из уровней ниже прикладного — там нет никаких самостоятельных, законченных, единиц данных — только кадры, фрагменты, потоки и прочее. Да и на прикладном они тоже не всегда есть. Если Вы имеете такое представление — поделитесь, реально любопытно.
Например, отдельно стоящий кэширующий прокси сервер.
SK>>Браузер работает на прикладном (osi 7), не опускаясь даже до представления (osi 6). ЕМ>Теперь у меня возникло подозрение, что Вы отождествляете прикладной уровень OSI с прикладным ПО, что в общем случае не так, а в обсуждаемом случае (отображение файловой системы ОС на ресурсы SMB) — совершенно не так.
Да, не так.
ЕМ>>>которые сами организуют кэширование этих файлов? SK>>notepad не подойдет? тогда тот же FAR. ЕМ>Каким образом (а главное — для чего) notepad или FAR самостоятельно организуют кэширование файлов?
Убедится очень просто — в notepad редактируешь файл. переключаешся в FAR и редактируешь этот-же файл.
SK>>На маленьких файлах служебный трафик связанный с файлом может превышать размер файла в разы. ЕМ>Да и ради бога. Те, кому он мешает, могли бы установить периодичность проверки актуальности, или вовсе отключить кэширование. А меня бы полностью устроила периодичность хоть раз в час, с возможностью принудительной ручной синхронизации. Уверен, что таких найдется еще минимум несколько миллионов.
И за этот час этот файл был изменен несколько сотен раз (процессом на самом сервере и,или по сети другими клиентами).
SK>>С кэшированием служебный трафик (каждые N времени перезапрашивать актуальность) быстро превращается в паразитный (и плюс нагрузка на CPU сервера). ЕМ>Я бы понял, если б Вы все это излагали хотя бы лет двадцать назад, а не сейчас, когда подобные изречения выглядят откровенно смешно на фоне гигабайт чисто паразитного трафика, и миллионов чисто паразитных операций CPU в секунду, что считается вполне в порядке вещей.
Двадцать лет назад я излагал ровно тоже самое. гигабиты гигагерцы и гигабайты не меняют ровным счетом ничего.
SK>>Если за 40 лет которые протокол использовался и развивался (корпорациями зарабатывающими на нём деньги), в нем добавили многое и исправили многое, а кэширование "не сделали"
ЕМ>Да что Вы уперлись в протокол? В обсуждаемом вопросе протокол вообще не актуален — он полностью лежит под файловым менеджером любой ОС, которая его использует. Для использования разумного кэширования нет ни малейшей нужды в модификации протокола.
Кроме того факта, что файл находится на другом хосте и им распоряжаются другие OS.
Все проблемы от жадности и глупости
Re[2]: Как заставить гостевую винду кэшировать Shared Folders?
Здравствуйте, Stanislaw K, Вы писали:
SK>отдельно стоящий кэширующий прокси сервер.
Который сможет кэшировать лишь на том же уровне, что и непосредственный клиент — то есть, на прикладном.
SK>в notepad редактируешь файл. переключаешся в FAR и редактируешь этот-же файл.
Описание слишком расплывчато, допускает различные толкования. Конкретнее можно?
SK>И за этот час этот файл был изменен несколько сотен раз (процессом на самом сервере и,или по сети другими клиентами).
Если так случилось — значит, в данном случае описанная схема не годится, и применять ее не нужно. А мне она годится на 146%, я хочу ее применять, но не могу понять, как.
SK>Двадцать лет назад я излагал ровно тоже самое. гигабиты гигагерцы и гигабайты не меняют ровным счетом ничего.
Да ладно, двадцать лет назад Ethernet 100 Mbit/s еще был мейнстримом, и даже средний HDD работал в разы быстрее, а нынче 10 Gbit/s уже практически мейнстрим, и многие не видят особой разницы между локальным диском и NFS.
SK>файл находится на другом хосте и им распоряжаются другие OS.
Какое это имеет значение, если клиентской стороне важно быстро выполнять повторные чтения файла, а его изменения в обозримом будущем не ожидается?
Re[11]: Как заставить гостевую винду кэшировать Shared Folders?
