30699 2015-02-03 23:00:58 +0300 Собрать glusterfs 3.6.2 2015-02-26 13:08:48 +0300 1 1 4 Development Sisyphus glusterfs3 unstable all Linux CLOSED FIXED P3 normal --- 1 lav rider rider qa-sisyphus oldest_to_newest 149992 0 lav 2015-02-03 23:00:58 +0300 Вышел 3.6.2. Надеюсь, он поможет. У нас репликация и файлы то двоятся, то не видны через ls, но существуют при обращении. http://blog.gluster.org/2015/01/glusterfs-3-6-2-ga-released/ 149996 1 rider 2015-02-04 13:36:54 +0300 Ага, только новый glusterfs тащит новый стек OFED, так что бэкпортировать в p7 его не получится. Ну или, если не используется rdma - собрать без него. 149998 2 lav 2015-02-04 15:56:42 +0300 (В ответ на комментарий №1) > Ага, только новый glusterfs тащит новый стек OFED, так что бэкпортировать в p7 > его не получится. > > Ну или, если не используется rdma - собрать без него. Не думаю, что кто-то использует gluster в ALT Linux, а тем более через rdma, так что точно собрать без него. 149999 3 rider 2015-02-04 16:14:37 +0300 gluster без rdma не чень интересен 150000 4 lav 2015-02-04 17:37:06 +0300 (В ответ на комментарий №3) > gluster без rdma не чень интересен Это можно будет обсудит отдельно в задаче «портирование в p7». Сейчас бы в Сизиф собрать. 150001 5 rider 2015-02-04 18:11:48 +0300 Да оно собирается нормально. task #139746 пройдёт в сизиф и glusterfs за ним пролезет. 150003 6 repository-robot 2015-02-04 22:24:17 +0300 glusterfs3-3.6.2-alt1 -> sisyphus: * Wed Feb 04 2015 Anton Farygin <rider@altlinux> 3.6.2-alt1 - new version (closes: #30699) 150077 7 lav 2015-02-08 18:11:26 +0300 Пока получилось с 3.6.2 только то, что клиенты ничего не могут смонтировать с ошибкой в логе: [2015-02-08 10:25:16.938819] I [MSGID: 100030] [glusterfsd.c:2018:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version (args: /usr/sbin/glusterfs --volfile-server=localhost --volfile-id=ftp-pub /var/ftp/pub) [2015-02-08 10:25:16.992922] E [glusterfsd-mgmt.c:1494:mgmt_getspec_cbk] 0-glusterfs: failed to get the 'volume file' from server [2015-02-08 10:25:16.993002] E [glusterfsd-mgmt.c:1596:mgmt_getspec_cbk] 0-mgmt: failed to fetch volume file (key:ftp-pub) [2015-02-08 10:25:16.993345] W [glusterfsd.c:1194:cleanup_and_exit] (--> 0-: received signum (0), shutting down [2015-02-08 10:25:16.993380] I [fuse-bridge.c:5599:fini] 0-fuse: Unmounting '/var/ftp/pub'. Такое бывает при неверном указании названия тома при монтировании, но в этом плане в fstab ничего не менялось. 150081 8 rider 2015-02-08 23:46:23 +0300 попробуй остановить том и запустить его снова. 150084 9 lav 2015-02-09 11:37:47 +0300 (В ответ на комментарий №8) > попробуй остановить том и запустить его снова. Да, у меня тоже была эта мысль. Остановил на всех узлах: # service glusterd stop # killall glusterfsd запустил. Всё равно failed to fetch volume file, и ещё иногда SegFault: [2015-02-09 08:24:36.376619] W [glusterfsd.c:1194:cleanup_and_exit] (--> 0-: received signum (15), shutting down 150085 10 lav 2015-02-09 11:43:59 +0300 (В ответ на комментарий №9) > (В ответ на комментарий №8) > > попробуй остановить том и запустить его снова. > Да, у меня тоже была эта мысль. Остановил на всех узлах: > # service glusterd stop > # killall glusterfsd > > запустил. > Всё равно failed to fetch volume file, и ещё иногда SegFault: > > [2015-02-09 08:24:36.376619] W [glusterfsd.c:1194:cleanup_and_exit] (--> 0-: > received signum (15), shutting down Гуглил, нашёл где-то совет, выполнил # gluster volume set ftp-pub allow-insecure on и стало монтироваться. Будем разбираться, что там. 150086 11 rider 2015-02-09 11:57:31 +0300 С таким лучше сразу сходить в апстрим ;( 150458 12 lav 2015-02-26 12:42:28 +0300 (В ответ на комментарий №7) > Пока получилось с 3.6.2 только то, что клиенты ничего не могут смонтировать с > ошибкой в логе: > [2015-02-08 10:25:16.938819] I [MSGID: 100030] [glusterfsd.c:2018:main] > 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version (args: > /usr/sbin/glusterfs --volfile-server=localhost --volfile-id=ftp-pub > /var/ftp/pub) > [2015-02-08 10:25:16.992922] E [glusterfsd-mgmt.c:1494:mgmt_getspec_cbk] > 0-glusterfs: failed to get the 'volume file' from server > [2015-02-08 10:25:16.993002] E [glusterfsd-mgmt.c:1596:mgmt_getspec_cbk] > 0-mgmt: failed to fetch volume file (key:ftp-pub) Потом разработчики спохватились и сообщили: The names of volfiles on disk was changed for improved rdma support. This change was introduced in 3.6.2. For reference the commit-ids of the changes are, 50952cd rdma: Client volfile name change for supporting rdma 605db00 rdma: Wrong volfile fetch on fuse mounting tcp,rdma volume via rdma This requires that the volfiles of existing volumes be regenerated, so that they use the new names. Without the regeneration, glusterd would be looking for files by the new names on a volfile fetch request but would not find them, which would lead to a mount failure. This regeneration is done by running glusterd in upgrade mode, 'glusterd --xlator-option *.upgrade=on -N'. https://bugzilla.redhat.com/show_bug.cgi?id=1191176 То есть на будущее, получается, надо вставить в post-install скрипт glusterd --xlator-option *.upgrade=on -N 150459 13 rider 2015-02-26 13:05:39 +0300 Если честно - меня это смущает, может быть всё-таки администратор будет делать такие операции ? 150460 14 lav 2015-02-26 13:08:48 +0300 (В ответ на комментарий №13) > Если честно - меня это смущает, может быть всё-таки администратор будет делать > такие операции ? Меня тоже. Думаю, что пока пусть администратор делает.