LINUX.ORG.RU

Вышла виртуальная ФС CAFS 0.0.5

 , ,


0

0

Вышла в свет первая публичная версия CAFS.

CAFS — это кеширующая read-only файловая система, которая может работать поверх локальной или сетевой ФС (sftp, samba, webdav, ...), а также может работать в offline (т.е. когда исходная фс недоступна).
Планируется, что cafs будет применяться у мобильных клиентов (ноутбуки, смартфоны), клиентов с медленными и нестабильными подключениями и для уменьшения нагрузки файл-серверов.

Ищу заинтересованых в проекте.

>>> Подробности



Проверено: Shaman007 ()

mice этош вроде мыши а не мышь, сходил по ссылке

alt0v14
()
Ответ на: комментарий от const86

По ссылке написано, что это только "пока". Но вот зачем туда пи-пи приплели... В общем лучше не буду. ;)

Bohtvaroh
()

Звучит неплохо, попробую прикрутить к macfuse

Farcaller
()

о ненене! только не питон!!!

anonymous
()
Ответ на: комментарий от anonymous

Наверное когда-нибудь потом будет си.

vrusinov
() автор топика

закапывайте. уже есть CODA, она умеет, и read, и write (и offline тоже), разрешает конфликты, когда offline write одного файла был произведен с разных машин и т.п.
и уже тыщу лет есть в linux.

anonymous
()

Если Python будет использоваться только в качестве bash'а, а не для реализации конечного фукнционала, то готов даже профинансировать сотней нефти. Могу невозбранно научить прекрасному языку "Си", на нём и пишите своё поделие.

anonymous
()
Ответ на: комментарий от anonymous

> закапывайте. уже есть CODA

кода это во первых монст, во вторых ты читал что автор пишет про удаленные серваки на других протоколах ? Вот вот. У автора идея в кеширующей фс а codа это такой рапределенный монстр из области afs. совершенно разные области применения.

kernel
()
Ответ на: комментарий от anonymous

>Если Python будет использоваться только в качестве bash'а, а не для реализации конечного фукнционала, то готов даже профинансировать сотней нефти. Могу невозбранно научить прекрасному языку "Си", на нём и пишите своё поделие.

Си? Сами на нем пишите, и не учите других на чем им писать.

alt0v14
()

Известные проблемы:

* невысокая производительности (причина: слишком простой кеш) * очистка кеша реализована пока не полностью * вызов statfs не реализован --- гы.. как только начнет учиться write - будет жестоко. А так - ничем от репликации или на худой конец rsync не отличается... Отстой.

anonymous
()
Ответ на: комментарий от Desu

ну это типа того что прикрутии к NFS. там тоже типа локальный кэш и туда ложат.. вот только надо ли?

anonymous
()

питон?

а жабаскрипт и вебдвануль будэ?

anonymous
()
Ответ на: комментарий от anonymous

а кода живая кстате? у кого есть опыт практического использования? в том числе на офлайне?

anonymous
()
Ответ на: комментарий от anonymous

Вот так куча проектов и погибает. Вот #ля зачем, вот почему. Вот оставили бы Фенду, не знали бы Линуха и спали бы спокойно. Не хотите человека поддержать а поумничать - лучше помолчите.

anonymous
()

1. Педононенавистинки идут сосать свою няшную сишку в другой тред. Или доказывают, что боттлнек в педоновской VM, а не в перебросе данных между ведром и юзерспейсом, где он, скорее всего, на самом деле находится.

1.1. Любителей няшной сишки с желанием сделать оное в ведре — одобряю.

2. Автора порицаю. Самое интересное — стратегия кэширования и управление ей — не описаны нигде, в исходники смотреть лень. В итоге не поймешь что за зверь.

anonymous
()
Ответ на: комментарий от tailgunner

Очередной лисапед. НА сайте не написано, чем это лучше существующих аналогов и вообще зачем он это начал писать.

anonymous
()

Да зря вы так ругаете. Обычный оупенсорс подход. Приглашать вот так разработчиков. Кроме лаб в школе/универе на С ничего не писали(90-95% ЛОРовцев?), ну так молчите.

Waterlaz
()

К автору вопрос: зачем оно надо, какие области применения предполагаются, объясните на пальцах как раюотает и как реализовано.

anonymous
()

отлично! как раз такой не хватало для smbnetfs - чтобы уменьшить время ожидания для списка ресурсов больших серверов и районных сетей!

anonymous
()
Ответ на: комментарий от anonymous

>отлично! как раз такой не хватало для smbnetfs - чтобы уменьшить время ожидания для списка ресурсов больших серверов и районных сетей!

Убивать, убивать, массово расстреливать, а выживших кастрировать! 

На кой, на кой член строить большие сервера и районые сети(!) на быдло-smb!!!!

AVL2
()
Ответ на: комментарий от alt0v14

На AFS. Кстати, кеширование на клиентах там уже есть.

anonymous
()

Новость написана так, что если б не первые комменты про зелёных мышек, то по ссылке бы не ходил :)

fractaler
()
Ответ на: комментарий от alt0v14

>ну посоветуйте нам на чем строить :)

ftp, http, bittorrent, nfs и sshfs в конце концов...

AVL2
()
Ответ на: комментарий от anonymous

1. Можно использовать mmap, (e)poll и другие кошерные методы взаимодействия (тысячи их!) 2. Конечно в ведре. Или на худой конец через FUSE (в конце концов, все боттлнеки, упирающиеся в переключение контекстов, там аккуратно засунуты в ведро). 3

neper
()
Ответ на: комментарий от kernel

> кода это во первых монст, во вторых ты читал что автор пишет про удаленные серваки на других протоколах ? Вот вот. У автора идея в кеширующей фс а codа это такой рапределенный монстр из области afs. совершенно разные области применения.

Отнюдь, в КОДА сильный упор на репликацию, агрессивное кеширование на клиенте вплоть до работы в offline mode. Вообще для любой задачи свой инструмент, когда мне нужна была репликация данных по нодам и максимально быстрый доступ к данным я отсновился на MogileFS (+ напильник).

oc
()
Ответ на: комментарий от anonymous

>Чем лучше CacheFS? >http://en.wikipedia.org/wiki/Cachefs ну была у меня задачка, был офис с линухой, были хомяки пользователей на обшем nfs сервере, заюзал я cachefs, только почемуто оно не стало в конечном шете быстрее работать, а клиент начал наобором безбожно тормазить, а потом еше регулярно какаянить херня происходила с кэшировалкой и файл какойнибуть блокировался нахер, фикселось только ребутом клиента, после чего CacheFS было закопано обратно. собирался писать свою кэшировалку на fuse+python а потом офис переехал, поставили гигабитную сеть и все стало работать более или менее. да еше, пришлось диры с настройками программ выносить симлинком на локальную фс.

anonymous
()
Ответ на: комментарий от anonymous

> Самое интересное — стратегия кэширования и управление ей — не описаны нигде
Там пока что все очень тупо и неоптимально, описывать собственно нечего.

vrusinov
() автор топика
Ответ на: комментарий от oc

> в КОДА сильный упор на репликацию, агрессивное кеширование на клиенте
> вплоть до работы в offline mode.


Именно это я и имел в виду под "распределенный монстр типа AFS". CODA это развитие идей AFS, не то чтобы пораженное NIH синдромом, но этому синдрому близкое. Изначальная задача была сделать распределенную файловую систему в которой будет "все" "правильным образом". Хороший такой, добротный, университетский аспирантно-профессорский мега-проект нацеленный в сторону индустриального стандарта. ИМХО одной из причин того что его сгубило(а заменой AFS и массовым он не стал - значит сгубило) была повышенная относительная требовательность к ресурсам во времена разработки. Ну и видимо людских ресурсов для МЕГА приставки нехватило.

> MogileFS


Глянем. Давно не осматривал ландшафт распределенных FS.

Мое ИМХО распределенным фс нужен аналог fuse. Может даже как расширение fuse. То есть некая "платформа" включающая в себя решения некоторых проблем и структурующее решение нерешенных. И в которой возможна реализация существующих рапределенных FS без существенной потери производительности.

kernel
()

Это чо? Чтоб если сеть отпала можно было порнуху досмотреть из кеша?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.