Tarantool не запускается из-за ошибки записи на диск

Пытаюсь запустить Tarantool в Docker с нуля (данных нет). Я использую команду Docker, которую они предлагают в Tutorial, и запускаю ее под Docker Desktop 2.4.0.0 в MacOS 10.15.6 (Каталина):

docker run \
  --name mytarantool \
  -d -p 3301:3301 \
  -v /data/dir/on/host:/var/lib/tarantool \
  tarantool/tarantool:2.5.1

(/data/dir/on/host заменяется моим локальным каталогом на ноутбуке). Тоже пробовал с последней версией 2.6.0.

Контейнер закрывается вскоре после запуска. docker logs показывает это:

2020-10-02 20:51:10.331 [1] main/103/tarantool-entrypoint.lua C> Tarantool 2.6.0-0-g47aa4e01e
2020-10-02 20:51:10.331 [1] main/103/tarantool-entrypoint.lua C> log level 5
2020-10-02 20:51:10.332 [1] main/103/tarantool-entrypoint.lua I> mapping 268435456 bytes for memtx tuple arena...
2020-10-02 20:51:10.332 [1] main/103/tarantool-entrypoint.lua I> mapping 134217728 bytes for vinyl tuple arena...
2020-10-02 20:51:10.335 [1] main/103/tarantool-entrypoint.lua I> instance uuid 1811ff01-13d1-45c8-9878-0974bf27ee40
2020-10-02 20:51:10.335 [1] iproto/101/main I> binary: bound to 0.0.0.0:3301
2020-10-02 20:51:10.335 [1] main/103/tarantool-entrypoint.lua I> initializing an empty data directory
2020-10-02 20:51:10.351 [1] main/103/tarantool-entrypoint.lua I> assigned id 1 to replica 1811ff01-13d1-45c8-9878-0974bf27ee40
2020-10-02 20:51:10.351 [1] main/103/tarantool-entrypoint.lua I> cluster uuid 12ca546b-29ea-4af3-a407-f24e91c0e636
2020-10-02 20:51:10.357 [1] snapshot/101/main I> saving snapshot `/var/lib/tarantool/00000000000000000000.snap.inprogress'
2020-10-02 20:51:10.361 [1] snapshot/101/main I> done
2020-10-02 20:51:10.364 [1] main/103/tarantool-entrypoint.lua I> ready to accept requests
2020-10-02 20:51:10.365 [1] main/103/tarantool-entrypoint.lua I> set 'log_level' configuration option to 5
2020-10-02 20:51:10.365 [1] main/105/checkpoint_daemon I> scheduled next checkpoint for Fri Oct  2 22:10:11 2020
2020-10-02 20:51:10.367 [1] main/103/tarantool-entrypoint.lua I> set 'listen' configuration option to "3301"
2020-10-02 20:51:10.367 [1] main/103/tarantool-entrypoint.lua I> set 'log_format' configuration option to "plain"
2020-10-02 20:51:10.384 [1] wal/101/main xlog.c:1026 !> SystemError /var/lib/tarantool/00000000000000000000.xlog: can't allocate disk space: Invalid argument
2020-10-02 20:51:10.384 [1] main/103/tarantool-entrypoint.lua txn.c:876 E> ER_WAL_IO: Failed to write to disk
2020-10-02 20:51:10.391 [1] main txn.c:876 E> ER_WAL_IO: Failed to write to disk
2020-10-02 20:51:10.391 [1] main F> fatal error, exiting the event loop

В то же время контейнер может создать 5,9 КБ 00000000000000000000.snap и 97Б 00000000000000000000.xlog файлов.

$ ls -hal
total 24
drwxr-xr-x@ 4 user  staff   128B  2 Oct 13:51 .
drwxr-xr-x  3 user  staff    96B  2 Oct 12:56 ..
-rw-r--r--  1 user  staff   5.9K  2 Oct 13:51 00000000000000000000.snap
-rw-r--r--  1 user  staff    97B  2 Oct 13:51 00000000000000000000.xlog

Если я запустил контейнер, не смонтировав локальный каталог, он завершится успешно.

Я предполагаю, что есть проблема с моей локальной файловой системой (или с тем, как она видна из контейнера) или, возможно, проблема с разрешением, но я не могу понять, что именно.

Если я exec в качестве оболочки в успешно запущенном контейнере, я вижу, что файл xlog больше и владельцем файлов является tarantool:tarantool.

$ docker exec -it 016 sh
/opt/tarantool # ls -hal /var/lib/tarantool/
total 1044
drwxr-xr-x    2 tarantoo tarantoo    4.0K Oct  2 20:40 .
drwxr-xr-x    1 root     root        4.0K Aug  2 16:31 ..
-rw-r--r--    1 tarantoo tarantoo    5.9K Oct  2 20:40 00000000000000000000.snap
-rw-r--r--    1 tarantoo tarantoo     273 Oct  2 20:40 00000000000000000000.xlog

Но с привязкой к каталогу это выглядит иначе:

$ docker run -it -p 3031:3031 -v /Users/user/project/storage:/var/lib/tarantool tarantool/tarantool:2.6.0 sh
/opt/tarantool # ls -hal /var/lib/tarantool/
total 16
drwxr-xr-x    4 tarantoo root         128 Oct  2 21:18 .
drwxr-xr-x    1 root     root        4.0K Aug  2 16:31 ..
-rw-r--r--    1 root     root        5.9K Oct  2 21:18 00000000000000000000.snap
-rw-r--r--    1 root     root          97 Oct  2 21:18 00000000000000000000.xlog

Я попытался сменить владельца для каталога и файлов:

$ docker run -it -p 3031:3031 -v /Users/user/project/storage:/var/lib/tarantool tarantool/tarantool:2.6.0 sh
/opt/tarantool # chown tarantool:tarantool -R /var/lib/tarantool/

И проверил, что изменения сохраняются после перезапуска контейнера:

$ docker run -it -p 3031:3031 -v /Users/user/project/storage:/var/lib/tarantool tarantool/tarantool:2.6.0 sh
/opt/tarantool # ls -hal /var/lib/tarantool/
total 16
drwxr-xr-x    4 tarantoo tarantoo     128 Oct  2 21:18 .
drwxr-xr-x    1 root     root        4.0K Aug  2 16:31 ..
-rw-r--r--    1 tarantoo tarantoo    5.9K Oct  2 21:18 00000000000000000000.snap
-rw-r--r--    1 tarantoo tarantoo      97 Oct  2 21:18 00000000000000000000.xlog

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

$ docker run -it -p 3031:3031 -v /Users/user/project/storage:/var/lib/tarantool tarantool/tarantool:2.6.0
Creating configuration file: /etc/tarantool/config.yml
Config:
---
force_recovery: false
memtx_dir: /var/lib/tarantool
listen: 3301
pid_file: /var/run/tarantool/tarantool.pid
vinyl_dir: /var/lib/tarantool
wal_dir: /var/lib/tarantool
```
2020-10-02 21:22:29.680 [1] main/103/tarantool-entrypoint.lua C> Tarantool 2.6.0-0-g47aa4e01e
2020-10-02 21:22:29.681 [1] main/103/tarantool-entrypoint.lua C> log level 5
2020-10-02 21:22:29.685 [1] main/103/tarantool-entrypoint.lua I> mapping 268435456 bytes for memtx tuple arena...
2020-10-02 21:22:29.685 [1] main/103/tarantool-entrypoint.lua I> mapping 134217728 bytes for vinyl tuple arena...
2020-10-02 21:22:29.687 [1] main/103/tarantool-entrypoint.lua I> instance uuid 74d33452-7f39-4ebf-a2f7-c1da6cb8c54b
2020-10-02 21:22:29.691 [1] main/103/tarantool-entrypoint.lua I> instance vclock {}
2020-10-02 21:22:29.691 [1] iproto/101/main I> binary: bound to 0.0.0.0:3301
2020-10-02 21:22:29.693 [1] main/103/tarantool-entrypoint.lua I> recovery start
2020-10-02 21:22:29.694 [1] main/103/tarantool-entrypoint.lua I> recovering from `/var/lib/tarantool/00000000000000000000.snap'
2020-10-02 21:22:29.695 [1] main/103/tarantool-entrypoint.lua I> cluster uuid 258099e8-803c-4a10-a3e0-57f6cd796f18
2020-10-02 21:22:29.708 [1] main/103/tarantool-entrypoint.lua I> assigned id 1 to replica 74d33452-7f39-4ebf-a2f7-c1da6cb8c54b
2020-10-02 21:22:29.709 [1] main/103/tarantool-entrypoint.lua I> recover from `/var/lib/tarantool/00000000000000000000.xlog'
2020-10-02 21:22:29.710 [1] main/103/tarantool-entrypoint.lua recovery.cc:156 W> file `/var/lib/tarantool/00000000000000000000.xlog` wasn't correctly closed
2020-10-02 21:22:29.713 [1] main/103/tarantool-entrypoint.lua I> ready to accept requests
2020-10-02 21:22:29.713 [1] main/103/tarantool-entrypoint.lua C> leaving orphan mode
2020-10-02 21:22:29.713 [1] main/103/tarantool-entrypoint.lua I> set 'log_level' configuration option to 5
2020-10-02 21:22:29.713 [1] main/105/checkpoint_daemon I> scheduled next checkpoint for Fri Oct  2 23:01:09 2020
2020-10-02 21:22:29.720 [1] main/103/tarantool-entrypoint.lua I> set 'listen' configuration option to "3301"
2020-10-02 21:22:29.720 [1] main/103/tarantool-entrypoint.lua I> set 'log_format' configuration option to "plain"
2020-10-02 21:22:29.723 [1] wal/101/main xlog.c:1026 !> SystemError /var/lib/tarantool/00000000000000000000.xlog: can't allocate disk space: Invalid argument
2020-10-02 21:22:29.723 [1] main/103/tarantool-entrypoint.lua txn.c:876 E> ER_WAL_IO: Failed to write to disk
2020-10-02 21:22:29.726 [1] main txn.c:876 E> ER_WAL_IO: Failed to write to disk
2020-10-02 21:22:29.726 [1] main F> fatal error, exiting the event loop

Как ни странно, разрешения вообще не изменились, если я проверяю это локально на своем ноутбуке. Я предполагаю, что это магия Docker, но я не уверен, как это работает, учитывая, что изменения разрешений сохраняются между перезапусками контейнера.

Но может вопрос не в разрешениях ... Что тогда? Как решить проблему?


person greatvovan    schedule 02.10.2020    source источник
comment
В журнале вижу эту ошибку: can't allocate disk space: Invalid argument. Вам не хватает места на диске? (Запуск df -h)   -  person Nick ODell    schedule 03.10.2020
comment
Дисковое пространство @NickODell в порядке, оно отображается в контейнере: grpcfuse 465.6G 405.0G 43.4G 90% /var/lib/tarantool. Но может быть процедура проверки дискового пространства некорректно работает в Docker ...   -  person greatvovan    schedule 03.10.2020
comment
Хм ... но это навело меня на мысль: в какой-то момент они представили технологию gRPC FUSE для обмена файлами, и она включена по умолчанию. Выключил и помогло! Теперь он работает!   -  person greatvovan    schedule 03.10.2020


Ответы (1)


Отвечая на свой вопрос.

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

Эту проблему можно решить, отключив функцию gRPC FUSE в настройках Docker Desktop. Предположительно (как говорится can't allocate disk space: Invalid argument) проблема в том, что эта реализация не поддерживает fallocate() с некоторыми конкретными параметрами (см. https://github.com/docker/for-mac/issues/4964#issuecomment-702748937).

ОБНОВЛЕНИЕ: если вы хотите использовать функцию gRPC FUSE для обмена файлами, рассмотрите возможность обновления до версии 2.4.2.0, в которой проблема была устранена.

person greatvovan    schedule 02.10.2020