EL
хоть из отдельного скрипта
Size: a a a
2020 September 03
EL
разберитесь почему у васс guest а не tarantool
I
разберитесь почему у васс guest а не tarantool
после того, как перешел на вызов call, guest не появляется
EL
он не появляется не потому что его нет, а потому что guest может делать call, поэтому и нет ошибки
EL
верните evaluate и снова появится
EL
то есть это все же похоже на проблему с правами, у вас один из юзеров не может читать apps, и скорее всего это
guestI
guest это юзер по умолчанию. execute denied видимо из за евала. попробуйте поменять на call:
$res = $tarantool->call('box.space._space:select')
MG
здравствуйте. хочу сделать fuse-файлуху на тарантуле. пока появился ряд вопросов, как это спроектировать.
у libfuse есть два варианта api -- highlevel(работа с путями) и lowlevel(работа с inode'ами)
т.к. в моём юзкейсе скорее всего это будет не прокси-файлуха, а ходилка в некоторый внешний стородж(со своей адресацией) -- пока кажется логичным юзать lowlevel-апи и хранить метаданные по inode'ам в коробке.
что непонятно -- как прицепить libfuse'овский eventloop к тарантулу. варианты:
1) сделать цикл файбером на tx-треде.
2) coio_call на fuse_loop -- чтобы оно крутилось на worker_pool_threads.
3) внешний C-демон, который с одного конца крутит цикл libfuse, а с другого -- ходит в тарантул по сети.
п.1 -- кажется что обработка транзакций и событий libfuse могут начать мешать друг другу.
п.2 -- т.к. колбеки вызываются на том цикле -- сразу оказываемся вне контекста файберов/кооперативной многозадачности.
п.3 -- нет настроения опять писать асинхронную сеть и заводить на ней tarantool-c :)
плюс п.3 -- можно крутить многопоточный цикл.
скажите, может я чего-то упускаю, и есть вариант как это всё связать просто?
у libfuse есть два варианта api -- highlevel(работа с путями) и lowlevel(работа с inode'ами)
т.к. в моём юзкейсе скорее всего это будет не прокси-файлуха, а ходилка в некоторый внешний стородж(со своей адресацией) -- пока кажется логичным юзать lowlevel-апи и хранить метаданные по inode'ам в коробке.
что непонятно -- как прицепить libfuse'овский eventloop к тарантулу. варианты:
1) сделать цикл файбером на tx-треде.
2) coio_call на fuse_loop -- чтобы оно крутилось на worker_pool_threads.
3) внешний C-демон, который с одного конца крутит цикл libfuse, а с другого -- ходит в тарантул по сети.
п.1 -- кажется что обработка транзакций и событий libfuse могут начать мешать друг другу.
п.2 -- т.к. колбеки вызываются на том цикле -- сразу оказываемся вне контекста файберов/кооперативной многозадачности.
п.3 -- нет настроения опять писать асинхронную сеть и заводить на ней tarantool-c :)
плюс п.3 -- можно крутить многопоточный цикл.
скажите, может я чего-то упускаю, и есть вариант как это всё связать просто?
MA
Взять s3fs, который смотрит в S3, написанный на тарантуле :)
MA
Ну и в голове не перестаёт вертеться вопрос: "зачем?"
AT
здравствуйте. хочу сделать fuse-файлуху на тарантуле. пока появился ряд вопросов, как это спроектировать.
у libfuse есть два варианта api -- highlevel(работа с путями) и lowlevel(работа с inode'ами)
т.к. в моём юзкейсе скорее всего это будет не прокси-файлуха, а ходилка в некоторый внешний стородж(со своей адресацией) -- пока кажется логичным юзать lowlevel-апи и хранить метаданные по inode'ам в коробке.
что непонятно -- как прицепить libfuse'овский eventloop к тарантулу. варианты:
1) сделать цикл файбером на tx-треде.
2) coio_call на fuse_loop -- чтобы оно крутилось на worker_pool_threads.
3) внешний C-демон, который с одного конца крутит цикл libfuse, а с другого -- ходит в тарантул по сети.
п.1 -- кажется что обработка транзакций и событий libfuse могут начать мешать друг другу.
п.2 -- т.к. колбеки вызываются на том цикле -- сразу оказываемся вне контекста файберов/кооперативной многозадачности.
п.3 -- нет настроения опять писать асинхронную сеть и заводить на ней tarantool-c :)
плюс п.3 -- можно крутить многопоточный цикл.
скажите, может я чего-то упускаю, и есть вариант как это всё связать просто?
у libfuse есть два варианта api -- highlevel(работа с путями) и lowlevel(работа с inode'ами)
т.к. в моём юзкейсе скорее всего это будет не прокси-файлуха, а ходилка в некоторый внешний стородж(со своей адресацией) -- пока кажется логичным юзать lowlevel-апи и хранить метаданные по inode'ам в коробке.
что непонятно -- как прицепить libfuse'овский eventloop к тарантулу. варианты:
1) сделать цикл файбером на tx-треде.
2) coio_call на fuse_loop -- чтобы оно крутилось на worker_pool_threads.
3) внешний C-демон, который с одного конца крутит цикл libfuse, а с другого -- ходит в тарантул по сети.
п.1 -- кажется что обработка транзакций и событий libfuse могут начать мешать друг другу.
п.2 -- т.к. колбеки вызываются на том цикле -- сразу оказываемся вне контекста файберов/кооперативной многозадачности.
п.3 -- нет настроения опять писать асинхронную сеть и заводить на ней tarantool-c :)
плюс п.3 -- можно крутить многопоточный цикл.
скажите, может я чего-то упускаю, и есть вариант как это всё связать просто?
Можно посмотреть интеграцию с коллбеками curl: https://github.com/tarantool/tarantool/blob/71a24b9f20d1f116d8d0f911dac94bbd7749cf87/src/curl.c
MF
> нет настроения опять писать асинхронную сеть
каждый раз кстати получается по новому
каждый раз кстати получается по новому
MA
Собственно более правильный вопрос: какую роль будет выполнять тут тарантул?
AT
п. 1: Кажется, это непреодолимо.