LINUX.ORG.RU

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

 , ,


0

0

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

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

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

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



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

А почему read-only? Конечно, с записью граблей много, но можно попробовать их все обойти.

const86 ★★★★★
()

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
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.