Какую сетевую ФС использовать?
банальный ftp/webdav должен быть лучше, но зависит конечно от реализации — облажаться можно везде.
если файлов много то лучше будет иметь копию по обе стороны и синхронизировать сразу всё.
барахло мелкой россыпью удобно гитом запушивать а в post-receive хуке делать чекаут, заодно получается бакап всей истории изменений.
если файлов много то лучше будет иметь копию по обе стороны и синхронизировать сразу всё.
барахло мелкой россыпью удобно гитом запушивать а в post-receive хуке делать чекаут, заодно получается бакап всей истории изменений.
банальный ftp/Судя по тому, что я видел с ftp - там для одного только просмотра файлов огромная куча команд выполняется. Если учесть, что выполнение каждой команды - 150мс, выйдут нереальные цифры.
А что с webdav?
AFS может быть? сам не пробовал
протекать будет, не зря же борются за уменьшение времени доступа к дискам
протекать будет, не зря же борются за уменьшение времени доступа к дискам
не зря же борются за уменьшение времени доступа к дискамС дисков ещё и ОС больше 9000 своих файлов читает. А с этим сетевым диском будет работать только пользователь руками и Eclipse (в нём - тоже только конкретные файлы, проект обновляться с такого диска будет только во времена латентности в пару милллисекунд и десятимегабитного канала).
AFS выглядит очень интересно, попробую.
не изобретай велосипед. используй любую vcs
Может для эклипса всё же лучше воспользоваться системами контроля версий?
А что с webdav?Я так понимаю, это расширение HTTP протокола. Мб. и меньше запросов по сравнению с ftp, но доп. информации передаётся явно больше.
Я так понимаю, это расширение HTTP протокола. Мб. и меньше запросов по сравнению с ftp, но доп. информации передаётся явно больше.запросов и подключений - меньше, доп. информации - никакой. замечательная штука.
не изобретай велосипед. используй любую vcs
Может для эклипса всё же лучше воспользоваться системами контроля версий?Система контроля версий в данном случае не подходит, нужен именно сетевой диск. Вносимые изменения должны мгновенно отражаться на этом удалённом сервере, а не тогда, когда закоммитишь. Сохранил - проверил - исправил - проверил - исправил - проверил - исправил - проверил - закоммитил в уже реальный репозиторий, с которым и другие люди работают (проверка и реальный коммит происходят на удалённом сервере, исправления и сохранение - на локальном компьютере).
Самба идеально работала на хорошем канале (латентность порядка 1мс). На нынешнем канале (или даже худшем - в будущем латентность увеличится до 150мс) она нежизнеспособна - но это не значит, что надо кардинально менять весь механизм работы, если есть и другие сетевые ФС.
запросов и подключений - меньше, доп. информации - никакой. замечательная штука.HTTP-заголовки + xml-формат списка файлов (явно тяжелее чем обычный список).
Впрочем, учитывая нативную (хоть и жутко глючную) поддержку вендой, в целом WebDav лучше.
мне кажется, дело не только в протоколе. Ищи кэширующие клиенты. У AFS точно такой есть, может и для сабы написали - они несколько ускорят работу.
мне кажется, дело не только в протоколе.Захожу фаром в папку - он подвисает на несколько секунд. В чём тут ещё, по-твоему, может быть дело?
Хотя кэширование, конечно, облегчило бы жизнь (если считать, что на сервере файлы не обновляются - иначе кэшированием только на стороне клиента не обойтись).
ешё раз говорю. На том же протоколе может работать более продвинутый клиент. Который кеширует метаданные и периодически проверяет их обновление (следит за флагами времени на сервере). Некоторые протоколы лучше приспособлены для такой работы, некоторые - хуже. Но так или иначе подобным образом можно сократить задержку для пользователя. Вот я и советую поискать другой самба клиент, а не тот, который у тебя тормозит. Это как работа с менеджерами закачки, по умолчанию получаешь неудобный протокол http, но если применить специальный клиент, то всё будет в порядке. Аналогия ясна?
Сохранил - проверил - исправил - проверил - исправил - проверил - исправил - проверил - закоммитил в уже реальный репозиторий, с которым и другие люди работают (проверка и реальный коммит происходят на удалённом сервере, исправления и сохранение - на локальном компьютере).кто мешает иметь нереальный репозиторий только для проверки?
То, что это геморрой, и к каждому "изменил" и "исправил" придётся добавлять "закоммитил" и "заапдейтился на сервере" (а если забыл это делать - то долго выяснять, почему работает не так, как ожидалось).
То, что это геморрой, и к каждому "изменил" и "исправил" придётся добавлять "закоммитил" и "заапдейтился на сервере" (а если забыл это делать - то долго выяснять, почему работает не так, как ожидалось)Чтобы не делать это самому и не забывать, есть make (не верю, что eclipse не поддерживает его или какой-то аналог). Тогда синхронизировать можно через rsync: если в локальной и удалённой системах хорошо работает обычный файловый кэш, будет быстро.
Захожу фаром в папку - он подвисает на несколько секунд. В чём тут ещё, по-твоему, может быть дело?скорее всего проблема в фаре
он небось по одному файлу читает...
Чтобы не делать это самому и не забывать, есть makeИ? Предлагаешь повесить этот make на CtrlS? В чём тогда вообще смысл этих приседаний?
скорее всего проблема в фареЛол, неужели вендовое API позволяет как-то иначе реализовать получение списка файлов/поддиректорий в каталоге?
он небось по одному файлу читает...
Впрочем, предлагаю отключить автообновление панелей. И, кстати, обычно можно нажать Esc чтобы прекратить чтение содержимого каталога.
Впрочем, предлагаю отключить автообновление панелей. И, кстати, обычно можно нажать Esc чтобы прекратить чтение содержимого каталогаЯ нажимаю Enter на папке (во второй панели при этом локальный диск фар зависает на несколько секунд, потом показывает содержимое нужной папки.
Да, я знаю, что, если в папке очень много файлов - в заголовке панели вместо её адреса будет написано "Чтение: сколькосейчаспрочитано файлов", и можно будет нажать Esc, чтобы остановить процесс. Это не тот случай.
Более того - тормоза, кажется, практически не зависят от количества файлов в папку. Даже при переходе в почти пустую папку наблюдается тот же несколькисекундный лаг. Насколько я помню, самба вообще изначально планировалась для использования только в локальных сетях, там неоткуда взяться большой латентности.
нет, , вот эта очень необходимая тебе хуйня никому в мире не нужна, и поэтому ее не придумали, не производят и не продают
Ага, ни одному человеку в мире не нужна сетевая ФС, работающая через интернет 
Если что, в этом треде были даны уже два ответа (AFS и WebDav).
Если что, в этом треде были даны уже два ответа (AFS и WebDav).
А еще тебе советовали vcs, но тебя это не устроило.
Если бы ты воспользовался поиском, то нашел бы обсуждение , но я уверен что ты будешь воротить нос от него и говорить, что это все не то.
Остается единственный вариант — тебе просто хочется потрындеть, поэтому ты и изображаешь какую-то проблему, и обсираешь все предложенные тебе варианты.
Поэтому самый правильный ответ на твой вопрос я уже дал.
Если бы ты воспользовался поиском, то нашел бы обсуждение , но я уверен что ты будешь воротить нос от него и говорить, что это все не то.
Остается единственный вариант — тебе просто хочется потрындеть, поэтому ты и изображаешь какую-то проблему, и обсираешь все предложенные тебе варианты.
Поэтому самый правильный ответ на твой вопрос я уже дал.
этих сетевых ФС пруд пруди. Просто никто не потестил, чтобы посоветовать что-либо определённое. Есть множество ФС с продвинутыми механизмами синхронизации, которые позволяют быстро работать через сеть
Если бы ты воспользовался поиском, то нашел бы обсуждение , но я уверен что ты будешь воротить нос от него и говорить, что это все не то.Если бы ты прочитал первый пост того треда, ты бы понял, что поставленная там задача ортогональна моей. Там искали распределённую ФС для быстрой сети; я же ищу любую ФС для медленной (с большой латентностью) сети.
Тут даже не в синхронизации дело. К примеру, лаг в те же 50мс (+пока пачка данных пролезает через канал) меня бы полностью устроил.
Тут явно просто какой-то очень неоптимальный алгоритм работы самбы (и фтп) при большой латентности.
Тут явно просто какой-то очень неоптимальный алгоритм работы самбы (и фтп) при большой латентности.
ты ещё скажи, что хочешь сетевую ФС через UDP, а то пока устанавливается соединение по TCP ты ждать устанешь.
Ещё раз. Время ожидания, равное латентности моего канала (или даже вдвое его превосходящее) меня полностью устраивает. Время ожидания в несколько секунд для любой операции - естественно, не устраивает. Самба явно оптимизирована для работы с быстрыми каналами по локальной сети; наверняка есть системы, оптимизированные для интернета. А если тебя устраивает время ожидания в несколько секунд - то ты просто слоупок, и что-то ты сегодня какой-то шустрый, не ожидал, что появишься в моём треде через каких-то десять часов после его создания.
всё правильно ты говоришь. А в идеале - избыточная система и distributed lock, которая позволит не перегонять всю инфу по сети, а держать актуальный кеш локально. Так что ищи просто продвинутые сетевые файловые системы и специфичные кеширующие клиенты к ним - они подойдут идеально. Вроде как AFS по описанию подходит. Будешь сам тестировать или подождёшь пока появятся в топике люди, с ней имевшие дело?
Я, кажется, ещё в самом начале написал, что буду пробовать AFS.
Кстати, никто случайно не знает способа искуственно поднять латентность соединения? А то хочется проверить качество работы прямо там - а нормально не выйдет, на работе пинги до сервера 1мс.
Кстати, никто случайно не знает способа искуственно поднять латентность соединения? А то хочется проверить качество работы прямо там - а нормально не выйдет, на работе пинги до сервера 1мс.
тебе просто необходима pohmelfs
Лол, неужели вендовое API позволяет как-то иначе реализовать получение списка файлов/поддиректорий в каталоге?согласен, прокололся.
нет там группового api
Кстати, никто случайно не знает способа искуственно поднять латентность соединения?dummynet какой-нибудь.
Лол, неужели вендовое API позволяет как-то иначе реализовать получение списка файлов/поддиректорий в каталоге?Есть такой приём, как read ahead.
Предлагаешь повесить этот make на CtrlS?Ну я не знаю, на какую кнопку тебе удобно повесить команду "make tests"
"Проверить" - это руками.
Есть такой приём, как read ahead.который в случае файлового менеджера не всегда полезен
как раз файловый менеджер читает директорию целиком
да и вообще довольно сложно представить, когда не нужен read ahead при чтении директории
да и вообще довольно сложно представить, когда не нужен read ahead при чтении директории
что от этого меняется?
компиляцию ты запускаешь ведь?
вот и копируй jar или что там получается
компиляцию ты запускаешь ведь?
вот и копируй jar или что там получается
компиляцию ты запускаешь ведь?Нет, это интерпретируемый язык. Между "сохранил" и "проверил" нет ничего, кроме "переключился из редактора в браузер".
Но ведь ты нажимаешь какую-то клавишу для сохранения файла? Забинди на нее копирование.
Тред не читал, но решил чего-нибудь сболтнуть?
Ты определись, что тебе нужно - файл на сервер доставить, или "ФС через интернет" и "подмонтировать в винде". Первую проблему тебе уже несколько раз решили.
Я, кажется, с самого начала говорю, что нужно именно второе.
Но это, конечно, очень по ХнСовски - придумать за человека совершенно другую проблему и с гордостью её решить.
Но это, конечно, очень по ХнСовски - придумать за человека совершенно другую проблему и с гордостью её решить.
Не кривляйся, ты уже выболтал настоящий юз-кейс где-то в середине первой страницы 
Незачем искать что-то в середине первой страницы, всё сказано ещё в первом посте.
Для тех, кто в танке, повторю. Надо, чтобы:
1) При попытке открыть произвольный файл он бы открылся практически мгновенно (не за несколько секунд, а за время, сравнимое с латентностью);
2) При попытке сохранить произвольный файл он бы оказался на сервере практически мгновенно (за время, сравнимое с латентностью).
А все эти фантазии про то, что мне, может быть, при каждом сохранении файла приходится запускать make - по меньшей мере странны. Если бы мне действительно приходилось это делать - тормоза ФС меня бы уже не волновали.
Ещё, что интересно - два правильных ответа уже были даны ещё в самом начале первой страницы, а затем пошёл какой-то флуд с выдумыванием проблем, не имеющих никакого отношения к исходному вопросу, и (какие мы умные!) их решением.
Для тех, кто в танке, повторю. Надо, чтобы:
1) При попытке открыть произвольный файл он бы открылся практически мгновенно (не за несколько секунд, а за время, сравнимое с латентностью);
2) При попытке сохранить произвольный файл он бы оказался на сервере практически мгновенно (за время, сравнимое с латентностью).
А все эти фантазии про то, что мне, может быть, при каждом сохранении файла приходится запускать make - по меньшей мере странны. Если бы мне действительно приходилось это делать - тормоза ФС меня бы уже не волновали.
Ещё, что интересно - два правильных ответа уже были даны ещё в самом начале первой страницы, а затем пошёл какой-то флуд с выдумыванием проблем, не имеющих никакого отношения к исходному вопросу, и (какие мы умные!) их решением.
> ты ещё скажи, что хочешь сетевую ФС через UDP
А что, таких не изобрели?
---
Druxa. Наши админы даже слышать не хотят про nfs в продакшене...
glebius. Любое безаппеляционное заявление может на самом деле быть разумным...
А что, таких не изобрели?
---
Druxa. Наши админы даже слышать не хотят про nfs в продакшене...
glebius. Любое безаппеляционное заявление может на самом деле быть разумным...
OpenVPN по UDP сделает из любой сетевой ФС работающую по UDP.
как-бы намекает на NFS
Из описания моей проблемы как бы понятно, что проблема не в использовании TCP, и одна лишь замена TCP на UDP приведёт в лучшем случае к двухкратному уменьшению тормозов.
Кстати, погуглил тут - похоже, что в SMB 2.0 (которое, вроде бы, поддерживается четвёртой самбой) эта проблема частично решена.
Правда, этой четвёртой самбы можно ещё несколько лет прождать.
Правда, этой четвёртой самбы можно ещё несколько лет прождать.
> как-бы намекает на NFS
как бы намекает, что UDP не выход, и если задержки раздражают,
надо перерабатывать сетевой обмен либо смириться с тем, что они будут.
---
"Первый ответ студента всегда неверный."
А. А. Кубасов
как бы намекает, что UDP не выход, и если задержки раздражают,
надо перерабатывать сетевой обмен либо смириться с тем, что они будут.
---
"Первый ответ студента всегда неверный."
А. А. Кубасов
а есть к нему кэширующие клиенты?
кто-то городит с fscache подпорки к nfs
Собрался поднять openafs. Самый простой мануал по установке, коорый нашёл: http://dietrichschroff.blogspot.com/2008/07/openafs-on-debia...
От выражений вроде
Буду сейчас смотреть на webdav.
От выражений вроде
On the server, type:я безудержно фалломорфирую.
#>kadmin.local -q "ank -randkey afs"
#>kadmin.local -q "ktadd -e des-cbc-crc:afs3 -k /etc/krb5.keytab.afs afs"
#>asetkey add foo /etc/krb5.keytab.afs afs
#>bosserver -noauth &
#>bos listhosts servername -noauth
#>bos create -server servername -instance ptserver -type simple -cmd /usr/lib/openafs/ptserver -cell domainname -noauth
#>bos adduser servername admin -cell domainname -noauth
#>bos listkeys servername -cell domainname -noauth
#>pts createuser -name admin -cell domainname -noauth
#>pts adduser admin system:administrators -cell domainname -noauth
#>pts membership admin -cell domainname -noauth
#>bos restart servername -all -cell domainname -noauth
#>bos create -server servername -instance fs -type fs -cmd /usr/lib/openafs/fileserver -cmd /usr/lib/openafs/volserver -cmd /usr/lib/openafs/salvager -cmd /usr/lib/openafs/vlserver -cell domainname -noauth
#>bos status servername fs -long -noauth
#>vos create -server servername -partition /vicepa -name root.afs -cell domainname -noauth
#>bos shutdown servername -wait
#>pkill bosserver
#>/etc/init.d/openafs-fileserver start
#>/etc/init.d/openafs-client start
#>kinit admin && klist
#>aklog && tokens
#>fs checkvolumes
#>fs setacl /afs system:anyuser rl
#>vos create servername /vicepa root.cell
#>fs mkmount /afs/domainname root.cell
#>fs setacl /afs/domainname system:anyuser rl
#>fs mkmount /afs/.domainname root.cell -rw
#>pts creategroup groupname -id -groupname
#>mkdir /afs/domainname/home
Буду сейчас смотреть на webdav.
Оставить комментарий
kruzer25
Почему-то на каналах с большой латентностью (даже если это только 50мс) самба уже невыносимо тормозит, совершенно невозможно работать, даже войти в папку в фаре - пара секунд (видимо, там делается несколько последовательных операций, и весь протокол планировался для близких серверов с латентностью канала, близкой к нулю).А какие ещё есть альтернативы, чтобы работало быстро и чтобы диск можно было подмонтировать в винде? Планируется работа с кучей мелких файлов по каналу с толщиной порядка мегабита с латентностью в будущем порядка 150мс.
Или это в принципе невозможно, и абстракция всегда будет протекать?