Синхронизация файловых систем на различных компьютерах
по-моему ты придумал какую-то фигню, которая будет делать всё что угодно, но не работать нормально.
5) хочется именно зеркальное копирование, а не просто монтирование сетевых дисков, т.к. надо эту систему еще и как бекапы использовать (хотя если не получится, то можно бекапы и отдельно прикрутить, но очень не хотелось бы).вот этот пункт вообще не понял.
http://en.wikipedia.org/wiki/List_of_file_systems#Distribute...
ты не заботал еще этот список? Там, кстати, не все известные мне системы. Мне кажется, что решение следует искать где-то среди них.
ты не заботал еще этот список? Там, кстати, не все известные мне системы. Мне кажется, что решение следует искать где-то среди них.
>вот этот пункт вообще не понял.
это товарищ намекает на drbd - network raid1
это товарищ намекает на drbd - network raid1
он хочет избыточность хранения. Все очевидно, и понятно зачем нужно.
Ну наиболее известные мне из списка (smb и nfs) как раз таки делают то, что мной описано выше: делают удаленный доступ к ФС сервера и исключают использование файлов когда компы не соединены сетью друг с другом.
Есть мнение, что двусторонняя синхронизация до добра не доведет - нарвешься на коллизии, как ты свои тонкости с настраиваемыми секундами не формулируй. Синхронизация д.б. односторонней, либо задача должна априори исключать возникновение коллизий.
конечно, каждая такая фс содержит distributed lock manager
То есть лучше всего сделать доступ с помощью, скажем, smb, а затем настроить одностороннее зеркалирование с сервера например на комп дома (у которого больше всего дискового пространства)?
и как этот лок спасет, если все клиенты отключатся друг от друга и каждый начнет свое писать в зеркалируемые данные?
посмотри внимательнее раздел Fault Tolerance Distributed File Systems. Мне кажется, что их можно настраивать на полную репликацию
Есть мнение, что двусторонняя синхронизация до добра не доведет - нарвешься на коллизии, как ты свои тонкости с настраиваемыми секундами не формулируй. Синхронизация д.б. односторонней, либо задача должна априори исключать возникновение коллизий.Есть мнение, что ты прав. Надо либо организовать работу с системой без коллизий, все проблемы должны быть решабельны инидивидуально, jabber можно заставить юзать какой-нить прокси-бэкэнд, который и будет сливать данные нескольких клиентов в одно history, либо надо ручками потом мержить файлы. В обоих случаях было бы полезны логи ФС с указанием на возможные коллизии.
По-крайней мере сразу снимается целая пачка "нюансов".
Ну а то, что бекапы д.б. отдельно от рабочих данных - это правильно.
Ну а то, что бекапы д.б. отдельно от рабочих данных - это правильно.
один из них мастер, после восстановления соединения слейв скачивает дифф
а со своей локальной (уже исправленной) копией что делает? в топку?
я думаю, достаточно простое решение - поставить во всех локациях железку на linux с drbd, экспортировать диск по nfs/cifs
для бэкапа настроить снапшоты на lvm
для бэкапа настроить снапшоты на lvm
ну да -)
в случае потери связи мастером может быть только один
в случае потери связи мастером может быть только один
эээ.... это не очень хорошее решение... надо посмотреть по времени модификации хотя бы (правда тогда еще надо время обязательно синхронизировать между компами).
Цепочка-то снимается... но наверное будет не очень хорошо если сидя на работе, где за траффиком следят (ограничения не жесткие, но если я скачаю 100 Гб за месяц меня по головке не погладят буду слушать музыку, лежащую на серваке.
Однако было бы удобнее, чтобы если будучи на работе, мне подадобилось кинуть в директорию с музыкой что-то новое, то это что-то само перекачалось домой и на сервак.
Однако было бы удобнее, чтобы если будучи на работе, мне подадобилось кинуть в директорию с музыкой что-то новое, то это что-то само перекачалось домой и на сервак.
ну так и работай как предлагаешь - на каждом компе храни локальные кеши (копии которые сами синхронизируются с сервера, а если что-то надо записать - пиши напрямую на сервер.
хм.... ну это кстати неплохая идея 
Кто что посоветует для автоматического одностороннего зеркалирования в направлени FreeBSD -> Windows ?
Кто что посоветует для автоматического одностороннего зеркалирования в направлени FreeBSD -> Windows ?
rsync.
А на винду он ставится только вместе с cygwin?
(вообще как-то боязно.... я едва ли не первый, кому понадобилось вести бэкап именно в направлении FreeBSD -> Windows
)
(вообще как-то боязно.... я едва ли не первый, кому понадобилось вести бэкап именно в направлении FreeBSD -> Windows
)Как показывает практика - коллизии неизбежны. И периодически файлы отправляются в топку по принципу "кто последний, тот и папа"
Как показывает практика - коллизии неизбежныКоллизий не бывает в принципе если мастер один.
Мб системы контроля версий (например, SVN) подойдут?
для музыки - вряд ли.
Чем это музыка так провинилась?
тем, что системы контроля версий разрабатывались для постоянно изменяющегося содержимого, а не для статики. т.е. хранить константы (в данном случае музыку конечно можно, но как-то это извращением попахивает.
Ну будут храниться различные версии папок, файлы будут в одной версии. Ничего ужасного не вижу.
а так - извращением попахивает и хранение мультимедиа в древовидной структуре типа папок-директорий
а так - извращением попахивает и хранение мультимедиа в древовидной структуре типа папок-директорий
Ну будут храниться различные версии папок, файлы будут в одной версии.а в чём фишка версий если содержимое одно и то же?
извращением попахивает и хранение мультимедиа в древовидной структуре типа папок-директорий
а как надо _хранить_ музыку, тобы было кошерно?
было б клево в теговой системе
захотел - в разбивке по артистам
захотел - по альбомам
итд
захотел - в разбивке по артистам
захотел - по альбомам
итд
хм, а может стоит различать функциональность ФС и БД?
не так уж эти понятия и различны
фс по сути есть простая узкоспециализированная бд, хранящая файлы
сейчас, для того, что хочу я, достаточно при добавлении нового трека раскидывать его симлинки/хардлинки по соответсвующим теговым папкам. Вопрос просто в написании управляющего скрипта.
фс по сути есть простая узкоспециализированная бд, хранящая файлы
сейчас, для того, что хочу я, достаточно при добавлении нового трека раскидывать его симлинки/хардлинки по соответсвующим теговым папкам. Вопрос просто в написании управляющего скрипта.
сейчас, для того, что хочу я, достаточно при добавлении нового трека раскидывать его симлинки/хардлинки по соответсвующим теговым папкам.Это будет некрасиво выглядеть. Кстати, а что ты будешь делать при переносе трека на другую локацию? ФС - иерархическая БД, но она заточена под жесткий диск (перемещение головок и иерархическое представление данных для хранения - самое очевидное и близкое к действительности. БД поверх - это уже прослойка.
она заточена под жесткий диск (перемещение головок и иерархическое представление данных для хранения - самое очевидное и близкое к действительностиКаким образом структура папок ближе к действительности, чем тэги? Файл - это набор секторов на жёстком диске, если не говорить об устройстве конкретной ФС - никакими папками там и не пахнет.
таким, что никакая инфа не дублируется, ФС хранит минимум информации для доступа к области дискового пространства. Можно и без дерева обходится, но тогда сильно возрастает время работы с единственной корневой папкой, так что иерархическое дерево - естественное решение проблемы быстродействия при просмотре папок. Тем более что вовсе не всем файлам нужно это БД.
Это будет некрасиво выглядеть. Кстати, а что ты будешь делать при переносе трека на другую локацию?Именно поэтому нужна правильная ФС =) Кстати, что-то подобное можно найти в fuse, оно там только очень сырое.
ФС - иерархическая БД, но она заточена под жесткий диск (перемещение головок и иерархическое представление данных для хранения - самое очевидное и близкое к действительности. БД поверх - это уже прослойка.Да никакой там принципиальной заточенности нету.
Просто так исторически сложилось, что у нас файлы в папках, папки и подпапки.
Я же уже привел пример небольшой надстройки, которая позволяет реализовать большую часть необходимого функционала. Там проблем только две - красиво перехватить изменения фс, и медленное создание новых вьюшек.
Майкрософт кстати планирует в след своей версии фс реализовать как раз что-то подобное. Очень жалею, что они ее не реализовали к висте.
вспомни как в том же NTFS чередуются полосы инфы с файлами и метаинформацией, причем данные директорий стараются держать рядом с теми файлам, к которым они относятся. Так что заточенность на устройство с произвольным доступом и долгим позиционированием у продвинутых ФС уже давно появилась.
Иерархичность как раз дает возможность разделять данные на непересекающиеся сеты.
Иерархичность как раз дает возможность разделять данные на непересекающиеся сеты.
Так что заточенность на устройство с произвольным доступом и долгим позиционированием у продвинутых ФС уже давно появилась.задоооогло до NTFS =)
очевидно музыка должна лежать как попало и индексироваться БД, выстраивание стройных древовидных классификаций оставим детям и ботаникам.
задоооогло до NTFS =)Вроде System V еще без этой фичи была. Но уже в FreeBSD переделали FS для поддержки такой фичи, ну а HPFS - это завершающий. MS все идеи воспринимает с большими задержками ибо тормоза. Но если уж даже они сподобились, значит исторически эта фича признана необходимой. Кстати, говорят что в Висте они наконец-то научились виджеты на рабочий стол вешать. Спустя десятки лет.
вспомни как в том же NTFS чередуются полосы инфы с файлами и метаинформацией, причем данные директорий стараются держать рядом с теми файлам, к которым они относятся.Чередуй полосы инфы и метаинфы, а данные по тегам держи рядом с проиндексированными файлами.
Чередуй полосы инфы и метаинфы, а данные по тегам держи рядом с проиндексированными файлами.неверно. иначе поиск по ним будет идти слишком долго.
тэги должны лежать компактной проиндексированной кучей.
видишь ли при иерархическом устройстве мы можем просто разделить файлы на несколько непересекающихся множеств. Этот файл лежит в этой директории, а этот файл - в той. При работе с реляционкой такое невозможно. У нас есть одно большое файлов, и несколько индексов со ссылками по разным переменным - времени создания, тегу автора, тегу исполнителя, etc. Как ты это будешь делить на два множества?
неверно. иначе поиск по ним будет идти слишком долго.это индекс должен лежать компактной кучей
тэги должны лежать компактной проиндексированной кучей.
ЗЫ Вообще очевидно, что подобная фс будет медленнее традиционной. Но не настолько, чтобы стоило отказываться от подобного удобства.
При работе с реляционкой такое невозможно. У нас есть одно большое файлов, и несколько индексов со ссылками по разным переменным - времени создания, тегу автора, тегу исполнителя, etc. Как ты это будешь делить на два множества?Понятно, что никак.
Но.
Кто сказал, что доступ к разделенным на две папки 4000 мп3шек будет ощутимо быстрее, чем доступ к тем же 4000 мп3шек, сваленным в одну кучу?
Если разделить файлы разного типа и индексировать их отдельно - музыка отдельно кино отдельно офис отдельно - этого будет более чем достаточно для нормальной производительности. Тем более сейчас весь индекс тегов можно будет легко держать в оперативке.
Кто сказал, что доступ к разделенным на две папки 4000 мп3шек будет ощутимо быстрее, чем доступ к тем же 4000 мп3шек, сваленным в одну кучу?А ты видел устройство БД/иерархии каталогов на iPod?
раскидали по папочкам, забили (вообще забили) на имена файлов, натянули поверх БД - и всё чудесно.
содержимое файлов - одно и то же, содержимое папок - пополняется новыми произведениями.Ну будут храниться различные версии папок, файлы будут в одной версии.а в чём фишка версий если содержимое одно и то же?
А ты видел устройство БД/иерархии каталогов на iPod?Если это вопрос ко мне - то видел. Это примерно то, к чему надо стремиться.
раскидали по папочкам, забили (вообще забили) на имена файлов, натянули поверх БД - и всё чудесно.
Только в данном случае один недостаток - процесс проходит не прозрачно, не на уровне фс, а на уровне софта. Именно поэтому работать без айтюнса с айподами очень тяжело.
Мы же говорим о переносе этой фичи на уровень фс.
Мы же говорим о переносе этой фичи на уровень фс.полностью не реально. разве что можно сделать интерфейс к тэговой БД из vfs уровня.
Мы же говорим о переносе этой фичи на уровень фс.мы говорим про "что бы натянуть на разные ФС, чтобы а-ля version control было"
на уровне ФС эти прелести с мультимедиа будут в WinFS (как я понимаю, отказываемся от иерархии в пользу кучи индексов над одной большой свалкой)
Именно поэтому работать без айтюнса с айподами очень тяжело.после перепрошивки становится легче
полностью не реально.вполне реально.
"приспосабливаться" к физической структуре можно и посредством кластеризованных индексов.
зачем? Богу - божье, кесарю - кесарево. ФС для хранения данных, БД - для поиска, у каждого свои задачи.
алепар к тому что сделать запрос к тэговой бд можно только из спец софта, а фс доступна всегда и везде.
ФС для хранения данных, БД - для поискасейчас порою возникает ситуация, когда ФС хранит только пару файлов БД, а внутри них уже играется СУБД
а фс доступна всегда и везде.Есть просто ряд (2)вызовов, переконвертированных в (3)процедуры, и простейший (1) софт для работы с файловой системой. Но ведь стоит поставить БД, как появляется (3)процедуры для запросов по БД, и как следствие простой консольный (1) софт для работы с БД. Если БД вместо ФС вставить в ядро, то получится полное равноправие
видишь ли при иерархическом устройстве мы можем просто разделить файлы на несколько непересекающихся множеств. Этот файл лежит в этой директории, а этот файл - в той. При работе с реляционкой такое невозможноесли метаинформация (например, каталоги) будут лежать в реляционке, то работать будет только быстрее,
т.к. можно будет считать в память хоть все дерево каталогов одним запросом.
сейчас же приходится бегать по всему диску и дергать головками.
При работе с реляционкой такое невозможнодля этого есть partitions
ps
какие операции ты считаешь, что будет быстрее на текущей структуре, чем на реляционке?
поиск файла? реляционка должна быстрее - т.к. есть индекс, и можно не вычитывать весь список
копирование кучи мелких файлов разбросанных по подкаталогам? опять же реляционка должна быстрее, т.к. все каталоги мы можем за один запрос взять.
копирование одного большего файла? так тут вообще не понятно в чем разница будет.
копирование одного каталога с кучей мелких файлов? опять реляционка быстрее, т.к. можно сразу файлы копировать в порядке их расположения на диске, идя по индексу "стартовая позиция файла", а не по именам
что-то еще?
Мы же говорим о переносе этой фичи на уровень фс.А MTP - разве не оно?
Но ведь стоит поставить БД, как появляется (3)процедуры для запросов по БД, и как следствие простой консольный (1) софт для работы с БД. Если БД вместо ФС вставить в ядро, то получится полное равноправиеdo not want
пока что все потуги сделать (1) приводили к убожеству.
если интерфейс будет работать с ls (1) и ln (1) то и о остальном (1) можно подумать.
А MTP - разве не оно?Во-первых, это протокол.
Во-вторых, там куча лимитаций по сравнению с фс.
Но направление верное.
Во-первых, это протокол.Вроде как, оно появляется как обычный съёмный диск в explorer-е?
Работа с ФС, можно сказать - тоже протокол.
какие операции ты считаешь, что будет быстрее на текущей структуре, чем на реляционке?1. Поиск файла по полному пути по любому будет быстрее в иерархической БД, они под это куда лучше заточены.
поиск файла? реляционка должна быстрее - т.к. есть индекс, и можно не вычитывать весь список
копирование кучи мелких файлов разбросанных по подкаталогам? опять же реляционка должна быстрее, т.к. все каталоги мы можем за один запрос взять.
копирование одного большего файла? так тут вообще не понятно в чем разница будет.
копирование одного каталога с кучей мелких файлов? опять реляционка быстрее, т.к. можно сразу файлы копировать в порядке их расположения на диске, идя по индексу "стартовая позиция файла", а не по именам
2. В иерархической БД тоже можно взять подкаталоги одним запросом. И все равно не получится быстрее, потому как она опять-таки под это заточена.
3. 4. Равнозначно.
Посчитай еще издержки.
если интерфейс будет работать с ls (1) и ln (1) то и о остальном (1) можно подумать.а зачем тебе старый набор команд? Тем более, что ты и не требовал его. Сначала ты хотел хоть какой-нить интерфейс
Вроде как, оно появляется как обычный съёмный диск в explorer-е?Насколько я помню, не как обычный. И я думаю, что по нему нельзя ходить обычными FindFirst/FindNext'ами. Его видят только специально обученные приложения, типа ехплорера и виндовс медиа плеера.
Работа с ФС, можно сказать - тоже протокол.
Но если можно - тогда уже лучше. Правда появится вторая проблема - как сделать локальный MTP сторедж =)
а зачем тебе старый набор команд? Тем более, что ты и не требовал его. Сначала ты хотел хоть какой-нить интерфейсНе хоть какой-то, а стандартный. Именно: fopen/... по именам из тегов.
Тогда все эти ls просто ничего не заметят. Именно этого и хочется.
Тред не читал. Попробуй посмотреть в сторону AFS (Andrew's File System)
Оставить комментарий
dangerr
Хотелось бы сделать такую фичу: на 4-х компах создать директорию, которая будет зеркально выглядеть на всех компах: то есть я записал туда что-то на одном компе и это автоматически оказалось на всех других (можно с некоторой разумной задержкой разумеется). При этом есть несколько тонкостей:0) На компах зоопарк ОС и ФС: на сервере FreeBSD (ufs2 дома win2008(ntfs на работе win2003(ntfs на ноуте Gentoo(ext3)
1) Можно считать постоянно включенным только сервер, остальные иногда выключаются, ноут вообще может неделю в столе лежать.
2) Между компами налажена "локалка" на основе openvpn, то есть можно использовать нешифрованные протоколы.
3) хотелось бы иметь возможность в течении некоторого задаваемого мною времени вернуть случайно удаленный файл, чтобы пока это время не пройдет он не синхронизировался.
4) С другой стороны, хотелось бы поместить туда часто обновляемые файлы, например историю im, причем не должно возникать коллизий, когда я оставил клиент включеным дома, уехал работать, мне написали туда, потом через минуту я зашел с работы (знаю про фишку jabbera быть залогиненным сразу во многих местах, но не пользуюсь ей, кроме того в icq у меня контактов на порядок больше) и стал общаться с человеком, нужно, чтобы клиент писал именно в актуальный файл истории.
5) хочется именно зеркальное копирование, а не просто монтирование сетевых дисков, т.к. надо эту систему еще и как бекапы использовать (хотя если не получится, то можно бекапы и отдельно прикрутить, но очень не хотелось бы).
Реально ли такое?