Я использую небольшой домашний сервер, на котором хранятся мои документы. Диски на этом сервере находятся в конфигурации RAID 1 (с использованием Linux md), и также периодически выполняется резервное копирование на внешний жесткий диск, чтобы я не потерял их. Однако я всегда получаю доступ к файлам с других компьютеров в домашней сети, используя общий ресурс SMB, и это приводит к значительному снижению скорости (особенно при подключении через WLAN). Это довольно неприятно при редактировании больших файлов, таких как, например, RAW цифровой камеры.
Искал решение этой проблемы. Он должен предложить какое-то локальное кеширование для ускорения доступа к файлам. Клиент не желает хранить копию всех данных на сервере, поскольку он состоит из очень большой коллекции фотографий, к большинству из которых я не буду часто обращаться. Вместо этого он должен кэшировать только те файлы, к которым осуществляется доступ, и синхронизировать изменения в фоновом режиме. В идеале, он также будет выполнять интеллектуальное упреждающее чтение (например, кэшировать файлы, которые находятся в том же каталоге, что и текущий открытый файл), но я полагаю, что это требует слишком много. Синхронизация должна быть автоматической (при изменении файла). Конфликтующие изменения файлов (одновременно на разных клиентах) вряд ли произойдут в моем случае использования, но я бы предпочел, чтобы они обрабатывались должным образом (уведомление для пользователя).
Пока я встречал следующие варианты:
что-то похожее на Dropbox. iFolder вроде бы единственное, что мне подходит, но его репутация (стабильность) и требования меня отталкивают.
Распределенная файловая система, такая как OpenAFS. Я не уверен, что это ускорит доступ к файлам. Наверное, это перебор для того, что мне нужно.
Возможно, NFS или даже Samba предлагают эти возможности. Я немного читал про Windows ' Автономные файлы, но его работа кажется ограниченной (по крайней мере, в Windows XP).
Поскольку это только для личного использования, я не хочу тратить много денег. Было бы предпочтительнее бесплатное решение. Кроме того, сервер должен работать в Linux, а мне нужен клиент как минимум для Windows.
Редактировать: С тех пор я установил OpenAFS (довольно сложный процесс). Кажется, он удовлетворяет большинство моих потребностей. Файлы кэшируются локально, что ускоряет доступ к кешированным файлам. Конечно, первый доступ к файлу все еще медленный. я в предвкушении Отключенный AFS планируется в будущем выпуске OpenAFS, так как это позволит предварительно кэшировать файлы. Это идеально подходит для редактирования наборов больших файлов, таких как RAW с камеры.
Вы можете кэшировать операции чтения и записи для NFSv4 с помощью FS-Cache. Red Hat написала хорошая документация.
FS-Cache - это постоянный локальный кеш, который может использоваться файловыми системами для приема данных, полученных из сети, и кэширования их на локальном диске. Это помогает минимизировать сетевой трафик для пользователей, получающих доступ к данным из файловой системы, смонтированной по сети (например, NFS).
Проблема с файловыми системами, которые работают в отключенном режиме: 1) одновременный доступ и 2) синхронизация. Если вам не нужен одновременный доступ, просто возьмите съемный жесткий диск и возьмите его с собой. Если вам нужен одновременный доступ, тогда у вас возникнут проблемы с синхронизацией, потому что как клиент, работающий с локальной копией, сообщает другим клиентам, что копия в сети теперь устарела? Если подумать, чем ближе вы подойдете к синхронизации, тем меньше смысла будет иметь кеш. Итак, обычно выигрывают две крайности; вы можете получить портативный диск или использовать файловую систему, которая не кэширует.
Что касается ваших фотографий, то, вероятно, вам действительно нужен локальный индекс, чтобы вы могли выполнять локальный поиск в индексе, но получать фактические файлы из сети. Это то, что работает на более высоком уровне, чем сама файловая система, поэтому причина, по которой вы не нашли то, что ищете, заключается в том, что вы ищете не то. :) Вероятно, вам стоит поискать программы для индексации изображений; Насколько я помню, это проблема, которая решалась несколькими способами.
Для более общего решения, вероятно, достаточно хорошо подойдет что-нибудь, вдохновленное Subversion, CVS или подобным.