profile
viewpoint

issue commentbcicen/ctop

Legend of CTOP

I agree. I'm sure you'll add а description in future releases. )

alex-v-jc

comment created time in a month

issue closedyandex-cloud/geesefs

Memory used

Подключено два бакета.

Заметил, что приложение потребляет достаточно много памяти для одно из них:

image

image

Это нормально?

Второй бакет:

image

image

closed time in a month

alex-v-jc

issue commentyandex-cloud/geesefs

Memory used

Ок, спасибо.

alex-v-jc

comment created time in a month

issue closedbcicen/ctop

Legend of CTOP

Hi. Sorry for my question.) But I couldn't find information anywhere on what the "plus" symbol means. Could you explain please?

image

Thanks.

closed time in a month

alex-v-jc

issue commentbcicen/ctop

Legend of CTOP

Oh, as always. ) Should have looked at the code. Thanks again! Good luck!

alex-v-jc

comment created time in a month

issue openedbcicen/ctop

Legend of CTOP

Hi. Sorry for my question.) But I couldn't find information anywhere on what the "plus" symbol means. Could you explain please?

image

Thanks.

created time in a month

issue commentyandex-cloud/geesefs

Memory used

А когда буферы скидываются? Есть ли механизм "высвободить" память?

Поясню.

На картинках выше, второй бакет, занимает (в памяти) совсем мало, хотя файлов в нем на порядки больше, чем в первом. При этом, второй бакет был просто подключен и операций с ним почти не проводилось. Тогда как в первом бакете, было много операций копирования/чтения/удаления.

Дальше, я прошелся по второму бакету ncdu и памяти для него заметно поприбавилось. То есть, логично, что кол-во памяти напрямую зависит от операций с бекетом.

Так вот вопрос. Когда память, отведенная для бакетов, высвободится, при условии, что операций с ними будет в разы меньше?

Скажем, первый бакет такой "большой" по памяти потому, что он был полностью сформирован на этом хосте (много файлов читалось/копировалось/удалялось), но, теперь, работа в нем будет проводиться (в основном) только в нескольких каталогах и операций будет много меньше, память освободится?

alex-v-jc

comment created time in a month

issue openedyandex-cloud/geesefs

Memory used

Подкючено два бакета.

Заметил, что приложение потребляет достаточно много памяти для одно из них:

image

image

Это нормально?

Второй бакет:

image

image

created time in a month

startedyandex-cloud/geesefs

started time in 2 months

issue commentyandex-cloud/geesefs

main.ERROR stacktrace from panic: runtime error: slice bounds out of range [:2] with capacity 0

Мда, странная ситуация. Второй день работает, правда, пока машина не под рабочей нагрузкой, но, тем не менее, с папкой пока проблем не было.

Понаблюдаю еще...

izedgo

comment created time in 2 months

issue commentyandex-cloud/geesefs

main.ERROR stacktrace from panic: runtime error: slice bounds out of range [:2] with capacity 0

Ну, ситуация стало несколько лучше, но не идеальной. Паники в логе нет, но, опять таки, в произвольный момент папка просто перестает "отзываться". Система "зависает" на попытке получить какой-то респонс. Если повезет, через какое-то время может отмереть по таймауту, вот в mc один раз я дождался, пока mc "сказал", все, не могу... А вот cp завесил напрочь. Все запуски были с логами, но... чего-то очевидного, как панику, я в них не нашел. Если больше никаких патчей не ожидается, могу выслать логи...

izedgo

comment created time in 2 months

issue commentyandex-cloud/geesefs

main.ERROR stacktrace from panic: runtime error: slice bounds out of range [:2] with capacity 0

Воспроизводится.

Есть лог такого сценария:

  • подключаемся
  • ходим по каталогам, смотрим содержимое,....
  • копируем ~1К мелких файлов
  • копирование выполняется
  • падение

Уверен, что, если бы я дольше "ползал" по каталогом, оно бы тоже упало.

Куда выслать лог?

izedgo

comment created time in 2 months

issue commentyandex-cloud/geesefs

main.ERROR stacktrace from panic: runtime error: slice bounds out of range [:2] with capacity 0

Повторно после паники можно монтировать, если сделать просто sudo umount точки монтирования. Просто после падения процесса-обработчика ФС точка монтирования остаётся в некорректном состоянии. А что делал вебсервер - просто раздавал статику? Запись шла туда?

примонтировать можно, но это не на долго это происходит постоянно

izedgo

comment created time in 2 months

issue closedyandex-cloud/geesefs

fuse.ERROR writeMessage: invalid argument [80 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]

Добрый день.

При попытке подключиться к Yandex Object Storage получаю такую ошибку:

-----------------------------------------------------
2021/09/30 16:19:52.769225 fuse.DEBUG Op 0x00000001        connection.go:411] <- init
2021/09/30 16:19:52.769257 fuse.DEBUG Op 0x00000001        connection.go:500] -> OK ()
2021/09/30 16:19:52.769278 fuse.ERROR writeMessage: invalid argument [80 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]
2021/09/30 16:19:52.769294 main.INFO File system has been successfully mounted.
2021/09/30 16:19:52.785066 s3.DEBUG DEBUG: Response s3/ListMultipartUploads Details:
---[ RESPONSE ]--------------------------------------

В итоге папка подключается, но:

ls -lha
ls: cannot access share: Connection refused

d??????????  ? ?    ?       ?            ? share

Что с дефолтными параметрами запуска:

./geesefs -f --debug_s3 --debug_fuse --debug share /mnt/share

что при изменения каких-либо параметров, в частности, --dir-mode и --file-mode, результат и ошибка не меняются.

При этом, запуск

./goofys -f --debug_s3 --debug_fuse share /mnt/share

приводит к корректному подключению:

-----------------------------------------------------
2021/09/30 16:34:03.086817 fuse.DEBUG Op 0x00000001        connection.go:408] <- init
2021/09/30 16:34:03.086842 fuse.DEBUG Op 0x00000001        connection.go:491] -> OK ()
2021/09/30 16:34:03.086871 main.INFO File system has been successfully mounted.
2021/09/30 16:34:03.098758 s3.DEBUG DEBUG: Response s3/ListMultipartUploads Details:
---[ RESPONSE ]--------------------------------------
drwxr-xr-x.  2 root root 4.0K Sep 30 16:34 share

Не могли бы указать причину и способ устранения? Спасибо!

closed time in 2 months

alex-v-jc

issue commentyandex-cloud/geesefs

fuse.ERROR writeMessage: invalid argument [80 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]

Будем считать вопрос уже не актуальным. Заставить работать на CentOS 7 я так и не смог. Было принято решение обвиться до CentOS 8. После обновления, все начиналось хорошо, но... увы, не долго. Подробности в issue #5

alex-v-jc

comment created time in 2 months

issue commentyandex-cloud/geesefs

main.ERROR stacktrace from panic: runtime error: slice bounds out of range [:2] with capacity 0

Окружение.

CentOS Linux release 8.3.2011

geesefs version 0.28.4

fuse-overlayfs-1.6-1.module_el8.4.0+886+c9a8d9ad.x86_64
fuse3-libs-3.2.1-12.el8.x86_64
fuse3-3.2.1-12.el8.x86_64
s3fs-fuse-1.90-1.el8.x86_64
fuse-common-3.2.1-12.el8.x86_64
fuse-2.9.7-12.el8.x86_64
fuse-libs-2.9.7-12.el8.x86_64

В произвольный момент возникает ситуация, указанная ниже. Можно воспроизвести со 100%-ной вероятностью просто при серфинге каталогов. Причем, зависимости от большого числа файлов не замечено.

Какие еще данные нужны для анализа?

2021/10/04 22:52:39.303735 main.ERROR stacktrace from panic: runtime error: slice bounds out of range [:2] with capacity 0
goroutine 86 [running]:
runtime/debug.Stack(0xc000da3930, 0x10af760, 0xc000376990)
        /opt/hostedtoolcache/go/1.16.8/x64/src/runtime/debug/stack.go:24 +0x9f
github.com/yandex-cloud/geesefs/api/common.LogPanic(0xc000da3f38)
        /home/runner/work/geesefs/geesefs/api/common/panic_logger.go:32 +0x76
panic(0x10af760, 0xc000376990)
        /opt/hostedtoolcache/go/1.16.8/x64/src/runtime/panic.go:965 +0x1b9
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70d80)
        /home/runner/work/geesefs/geesefs/internal/dir.go:840 +0x165
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70c00)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70780)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70300)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000473e00)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000473980)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc0002e9c80)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc0002e8c00)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*DirHandle).ReadDir(0xc000d92780, 0x0, 0x0, 0xc000da8530, 0x1, 0x1)
        /home/runner/work/geesefs/geesefs/internal/dir.go:572 +0x210
github.com/yandex-cloud/geesefs/internal.(*Goofys).ReadDir(0xc0000b0000, 0x133b0b8, 0xc000c90720, 0xc000a3ec00, 0x0, 0x0)
        /home/runner/work/geesefs/geesefs/internal/goofys.go:1127 +0x265
github.com/yandex-cloud/geesefs/api/common.FusePanicLogger.ReadDir(0x134b380, 0xc0000b0000, 0x133b0b8, 0xc000c90720, 0xc000a3ec00, 0x0, 0x0)
        /home/runner/work/geesefs/geesefs/api/common/panic_logger.go:101 +0x8c
github.com/jacobsa/fuse/fuseutil.(*fileSystemServer).handleOp(0xc000684460, 0xc000118680, 0x133b0b8, 0xc000c90720, 0xf4b320, 0xc000a3ec00)
        /home/runner/go/pkg/mod/github.com/vitalif/fusego@v0.0.0-20210901111451-575b70f3fd32/fuseutil/file_system.go:183 +0xc87
created by github.com/jacobsa/fuse/fuseutil.(*fileSystemServer).ServeOps
        /home/runner/go/pkg/mod/github.com/vitalif/fusego@v0.0.0-20210901111451-575b70f3fd32/fuseutil/file_system.go:123 +0x1a5

2021/10/04 22:52:39.303756 fuse.DEBUG Op 0x00000040        connection.go:502] -> Error: "input/output error"
2021/10/04 22:52:39.303767 fuse.ERROR *fuseops.ReadDirOp error: input/output error
izedgo

comment created time in 2 months

issue closedyandex-cloud/geesefs

main.ERROR stacktrace from panic: runtime error: slice bounds out of range

Окружение.

4.18.0-240.10.1.el8_3.x86_64
CentOS Linux release 8.3.2011

geesefs version 0.28.4

fuse-overlayfs-1.6-1.module_el8.4.0+886+c9a8d9ad.x86_64
fuse3-libs-3.2.1-12.el8.x86_64
fuse3-3.2.1-12.el8.x86_64
s3fs-fuse-1.90-1.el8.x86_64
fuse-common-3.2.1-12.el8.x86_64
fuse-2.9.7-12.el8.x86_64
fuse-libs-2.9.7-12.el8.x86_64

В произвольный момент возникает ситуация, указанная ниже. Можно воспроизвести со 100%-ной вероятностью просто при серфинге каталогов. Причем, зависимости от большого числа файлов не замечено.

Какие еще данные нужны для анализа?

2021/10/04 22:52:39.303735 main.ERROR stacktrace from panic: runtime error: slice bounds out of range [:2] with capacity 0
goroutine 86 [running]:
runtime/debug.Stack(0xc000da3930, 0x10af760, 0xc000376990)
        /opt/hostedtoolcache/go/1.16.8/x64/src/runtime/debug/stack.go:24 +0x9f
github.com/yandex-cloud/geesefs/api/common.LogPanic(0xc000da3f38)
        /home/runner/work/geesefs/geesefs/api/common/panic_logger.go:32 +0x76
panic(0x10af760, 0xc000376990)
        /opt/hostedtoolcache/go/1.16.8/x64/src/runtime/panic.go:965 +0x1b9
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70d80)
        /home/runner/work/geesefs/geesefs/internal/dir.go:840 +0x165
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70c00)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70780)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70300)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000473e00)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000473980)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc0002e9c80)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc0002e8c00)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*DirHandle).ReadDir(0xc000d92780, 0x0, 0x0, 0xc000da8530, 0x1, 0x1)
        /home/runner/work/geesefs/geesefs/internal/dir.go:572 +0x210
github.com/yandex-cloud/geesefs/internal.(*Goofys).ReadDir(0xc0000b0000, 0x133b0b8, 0xc000c90720, 0xc000a3ec00, 0x0, 0x0)
        /home/runner/work/geesefs/geesefs/internal/goofys.go:1127 +0x265
github.com/yandex-cloud/geesefs/api/common.FusePanicLogger.ReadDir(0x134b380, 0xc0000b0000, 0x133b0b8, 0xc000c90720, 0xc000a3ec00, 0x0, 0x0)
        /home/runner/work/geesefs/geesefs/api/common/panic_logger.go:101 +0x8c
github.com/jacobsa/fuse/fuseutil.(*fileSystemServer).handleOp(0xc000684460, 0xc000118680, 0x133b0b8, 0xc000c90720, 0xf4b320, 0xc000a3ec00)
        /home/runner/go/pkg/mod/github.com/vitalif/fusego@v0.0.0-20210901111451-575b70f3fd32/fuseutil/file_system.go:183 +0xc87
created by github.com/jacobsa/fuse/fuseutil.(*fileSystemServer).ServeOps
        /home/runner/go/pkg/mod/github.com/vitalif/fusego@v0.0.0-20210901111451-575b70f3fd32/fuseutil/file_system.go:123 +0x1a5

2021/10/04 22:52:39.303756 fuse.DEBUG Op 0x00000040        connection.go:502] -> Error: "input/output error"
2021/10/04 22:52:39.303767 fuse.ERROR *fuseops.ReadDirOp error: input/output error

closed time in 2 months

alex-v-jc

issue commentyandex-cloud/geesefs

main.ERROR stacktrace from panic: runtime error: slice bounds out of range

Сорри, не заметил #5 Добавлю туда, это закрываем.

alex-v-jc

comment created time in 2 months

issue openedyandex-cloud/geesefs

main.ERROR stacktrace from panic: runtime error: slice bounds out of range

Окружение.

4.18.0-240.10.1.el8_3.x86_64
CentOS Linux release 8.3.2011

geesefs version 0.28.4

fuse-overlayfs-1.6-1.module_el8.4.0+886+c9a8d9ad.x86_64
fuse3-libs-3.2.1-12.el8.x86_64
fuse3-3.2.1-12.el8.x86_64
s3fs-fuse-1.90-1.el8.x86_64
fuse-common-3.2.1-12.el8.x86_64
fuse-2.9.7-12.el8.x86_64
fuse-libs-2.9.7-12.el8.x86_64

В произвольный момент возникает ситуация, указанная ниже. Можно воспроизвести со 100%-ной вероятностью просто при серфинге каталогов. Причем, зависимости от большого числа файлов не замечено.

Какие еще данные нужны для анализа?

2021/10/04 22:52:39.303735 main.ERROR stacktrace from panic: runtime error: slice bounds out of range [:2] with capacity 0
goroutine 86 [running]:
runtime/debug.Stack(0xc000da3930, 0x10af760, 0xc000376990)
        /opt/hostedtoolcache/go/1.16.8/x64/src/runtime/debug/stack.go:24 +0x9f
github.com/yandex-cloud/geesefs/api/common.LogPanic(0xc000da3f38)
        /home/runner/work/geesefs/geesefs/api/common/panic_logger.go:32 +0x76
panic(0x10af760, 0xc000376990)
        /opt/hostedtoolcache/go/1.16.8/x64/src/runtime/panic.go:965 +0x1b9
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70d80)
        /home/runner/work/geesefs/geesefs/internal/dir.go:840 +0x165
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70c00)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70780)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000b70300)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000473e00)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc000473980)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc0002e9c80)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*Inode).removeAllChildrenUnlocked(0xc0002e8c00)
        /home/runner/work/geesefs/geesefs/internal/dir.go:828 +0xd3
github.com/yandex-cloud/geesefs/internal.(*DirHandle).ReadDir(0xc000d92780, 0x0, 0x0, 0xc000da8530, 0x1, 0x1)
        /home/runner/work/geesefs/geesefs/internal/dir.go:572 +0x210
github.com/yandex-cloud/geesefs/internal.(*Goofys).ReadDir(0xc0000b0000, 0x133b0b8, 0xc000c90720, 0xc000a3ec00, 0x0, 0x0)
        /home/runner/work/geesefs/geesefs/internal/goofys.go:1127 +0x265
github.com/yandex-cloud/geesefs/api/common.FusePanicLogger.ReadDir(0x134b380, 0xc0000b0000, 0x133b0b8, 0xc000c90720, 0xc000a3ec00, 0x0, 0x0)
        /home/runner/work/geesefs/geesefs/api/common/panic_logger.go:101 +0x8c
github.com/jacobsa/fuse/fuseutil.(*fileSystemServer).handleOp(0xc000684460, 0xc000118680, 0x133b0b8, 0xc000c90720, 0xf4b320, 0xc000a3ec00)
        /home/runner/go/pkg/mod/github.com/vitalif/fusego@v0.0.0-20210901111451-575b70f3fd32/fuseutil/file_system.go:183 +0xc87
created by github.com/jacobsa/fuse/fuseutil.(*fileSystemServer).ServeOps
        /home/runner/go/pkg/mod/github.com/vitalif/fusego@v0.0.0-20210901111451-575b70f3fd32/fuseutil/file_system.go:123 +0x1a5

2021/10/04 22:52:39.303756 fuse.DEBUG Op 0x00000040        connection.go:502] -> Error: "input/output error"
2021/10/04 22:52:39.303767 fuse.ERROR *fuseops.ReadDirOp error: input/output error

created time in 2 months

issue commentyandex-cloud/geesefs

fuse.ERROR writeMessage: invalid argument [80 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]

Просто yum install fuse3 результата не поменял. При этом, избавиться от fuse-libs-2.9.2-11.el7.x86_64 не получается (есть зависимости).

Сейчас в системе:

# rpm -qa | grep fuse

fuse3-libs-3.6.1-4.el7.x86_64
fuse3-3.6.1-4.el7.x86_64
fuse-libs-2.9.2-11.el7.x86_64
fuse-2.9.2-11.el7.x86_64

Какую версию и библиотеку будет использовать GeeseFS? Надо что-то где-то указывать?

Я повторил установку на VM в другом ДЦ, с такой же системой. В итоге, имеем

centos-release-7-6.1810.2.el7.centos.x86_64
vmlinuz-3.10.0-957.el7.x86_64

Установку fuse3:

# yum install fuse3

...
Running transaction
  Installing : fuse3-libs-3.6.1-4.el7.x86_64                                                                                                                                                                                                                          1/2
  Installing : fuse3-3.6.1-4.el7.x86_64                                                                                                                                                                                                                               2/2
  Verifying  : fuse3-libs-3.6.1-4.el7.x86_64                                                                                                                                                                                                                          1/2
  Verifying  : fuse3-3.6.1-4.el7.x86_64                                                                                                                                                                                                                               2/2

Installed:
  fuse3.x86_64 0:3.6.1-4.el7

Dependency Installed:
  fuse3-libs.x86_64 0:3.6.1-4.el7
# rpm -qa | grep fuse

fuse3-libs-3.6.1-4.el7.x86_64
fuse3-3.6.1-4.el7.x86_64
fuse-libs-2.9.2-11.el7.x86_64
fuse-2.9.2-11.el7.x86_64

Запуск:

/usr/local/bin/geesefs -f --debug_s3 --debug_fuse --debug cgp.share /mnt/share/

Результат:

2021/10/01 20:54:37.248907 fuse.DEBUG Ref 1 .. [1]
2021/10/01 20:54:37.249379 fuse.DEBUG Op 0x00000001        connection.go:411] <- init
2021/10/01 20:54:37.249413 fuse.DEBUG Op 0x00000001        connection.go:500] -> OK ()
2021/10/01 20:54:37.249494 fuse.ERROR writeMessage: invalid argument [80 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]

Очень хочется решить проблему, особенно, принимая во внимание то, что у вас все работает на аналогичной системе. Есть идеи куда копать? Спасибо!

alex-v-jc

comment created time in 2 months

issue commentyandex-cloud/geesefs

fuse.ERROR writeMessage: invalid argument [80 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]

Ок, попробую, надо будет тогда удалить fuse2, наверное, отпишусь по результату... Но, с fuse-2.9.7-12.el8.x86_64 на CentOS 8 проблем не возникает.

alex-v-jc

comment created time in 2 months

issue commentyandex-cloud/geesefs

fuse.ERROR writeMessage: invalid argument [80 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]

я постоянно тестирую на яндексовом s3 (и в яндексовых вм)

Да, я тоже работаю с Yandex Cloud и с подключаюсь с их VM.

Не понятно, проверил даже на centos 7, всё равно работает почему-то :-)

У меня есть VM с CentOS 8, проверил на ней, проблем не возникло. Все же, есть зависимости от ОС?

Если это так, это немного печально, так как две VM, которые нуждаются в подключении хранилища, причем именно через GeeseFS из-за работы с большим количеством маленьких файлов, используют CentOS 7. Не хотелось бы поднимать вопрос об обновлении ОС.

alex-v-jc

comment created time in 2 months

issue commentyandex-cloud/geesefs

fuse.ERROR writeMessage: invalid argument [80 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]

Не понятно, проверил даже на centos 7, всё равно работает почему-то :-)

Вот тут подробнее ) Я где-то пропустил, что на CentOS 7 не должно работать? У меня как раз CentOS 7

Linux vmlinuz-3.10.0-957.5.1.el7.x86_64
(gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) ) #1 SMP Fri Feb 1 14:54:57 UTC 2019

centos-release-7-6.1810.2.el7.centos.x86_64

Учитывая, что есть какое-то сообщение о fuse, подскажите версию ядра?

fuse-2.9.2-11.el7.x86_64

geesefs 0.28.4

С s3fs V1.90 проблем нет. С goofys 0.24.0-45b8d78375af1b24604439d2e60c567654bcdf88 тоже.

alex-v-jc

comment created time in 2 months

fork alex-v-jc/geesefs

Finally, a good FUSE FS implementation over S3

fork in 2 months

issue openedyandex-cloud/geesefs

fuse.ERROR writeMessage: invalid argument [80 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]

Добрый день.

При попытке подключиться к Yandex Object Storage получаю такую ошибку:

-----------------------------------------------------
2021/09/30 16:19:52.769225 fuse.DEBUG Op 0x00000001        connection.go:411] <- init
2021/09/30 16:19:52.769257 fuse.DEBUG Op 0x00000001        connection.go:500] -> OK ()
2021/09/30 16:19:52.769278 fuse.ERROR writeMessage: invalid argument [80 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0]
2021/09/30 16:19:52.769294 main.INFO File system has been successfully mounted.
2021/09/30 16:19:52.785066 s3.DEBUG DEBUG: Response s3/ListMultipartUploads Details:
---[ RESPONSE ]--------------------------------------

В итоге папка подключается, но с такими атрибутами:

d??????????  ? ?    ?       ?            ? share

Что с дефолтными параметрами запуска:

./geesefs -f --debug_s3 --debug_fuse --debug share /mnt/share

что при изменения каких-либо параметров, в частности, --dir-mode и --file-mode, результат и ошибка не меняются.

При этом, запуск

./goofys -f --debug_s3 --debug_fuse share /mnt/share

приводит к корректному подключению:

-----------------------------------------------------
2021/09/30 16:34:03.086817 fuse.DEBUG Op 0x00000001        connection.go:408] <- init
2021/09/30 16:34:03.086842 fuse.DEBUG Op 0x00000001        connection.go:491] -> OK ()
2021/09/30 16:34:03.086871 main.INFO File system has been successfully mounted.
2021/09/30 16:34:03.098758 s3.DEBUG DEBUG: Response s3/ListMultipartUploads Details:
---[ RESPONSE ]--------------------------------------
drwxr-xr-x.  2 root root 4.0K Sep 30 16:34 share

Не могли бы указать причину и способ устранения? Спасибо!

created time in 2 months

more