Hi guys, Need your help with ZFS on FreeBSD. Maybe someone else saw the similar problems.
Sorry for Russian in email below, but maybe author can translate it to English :) -- Best regards, Igor Kozhukhov On 15/03/16 20:56, "DemIS" <[email protected]> wrote: >Понял, > >Спасибо! > >Будем искать... > > >15.03.2016, 20:22, "Igor Kozhukhov" <[email protected]>: >> Привет :) >> >> Приятно видеть что русский народ все же тожа копает ZFS :) >> >> Расскажу сразу про себя немного. >> >> Я работаю с illumos - http://www.illumos.org/ >> >> Это форк от OpenSolaris. >> У меня есть свой проект - frok form illumos - http://www.dilos.org >> >> На BSD дел с ZFS не имел, так что тут могу дать совет - пробовать писать >> IRC #openzfs или посмотреть контакты на openzfs.org >> >> ZFS портирован на FreeBSD - он там не нативный был и есть - его пилят и >> портируют патчи из illumos. >> >> Проблема интересная, но к сожалению, такие проблемы очень тяжело ловить, >> потому как нету четкого сценария для reproduce. >> Для начала - можете попробовать подписаться на openzfs-developers & >> illumos-dev maillist - и там описать свою проблему на аглицком. >> К сожалению, я не могу туда запостить - боюсь что кроме меня и еще >> некоторого народу никто не прочитает... >> >> По вашему логу: >> >> #3 0xffffffff81c1b209 at acl_from_aces+0x1c9 >> #4 0xffffffff81cd27e6 at zfs_freebsd_getacl+0xa6 >> >> Исходя вот из этих строчек можно предположить что тут именно bsd >>specific >> ported + ACL over. >> >> К сожалению, как писал ранее, не имел дел с FreeBSD & ZFS on it. >> >> -- >> Best regards, >> Igor Kozhukhov >> >> On 15/03/16 19:45, "DemIS" <[email protected]> wrote: >> >>> Здравствуйте, Игорь, >>> >>> нашел Ваш адрес на >>> >>>https://github.com/ahrens/illumos/commits/DLPX-36920-zfs-send-should-pad >>>-p >>> ayloads-if-they-are-too-small >>> >>> Где в коде есть строки: >>> >>> * Copyright 2012 Milan Jurik. All rights reserved. >>> * Copyright (c) 2012, Joyent, Inc. All rights reserved. >>> * Copyright (c) 2013 Steven Hartland. All rights reserved. >>> - * Copyright 2013 Nexenta Systems, Inc. All rights reserved. >>> * Copyright 2016 Igor Kozhukhov <[email protected]>. >>> + * Copyright 2016 Nexenta Systems, Inc. >>> >>> Возможно, со своим вопросом, я просто не по адресу, тогда извините. >>> Приведенные ниже по тексту ссылки не сочтите за рекламу. >>> >>> Суть проблемы (копипаст из моего письма одному коллеге): >>> ==================================================== >>> Цитата: >>> Да если-бы я сам знал... >>> >>> Примерная последовательность возникновения проблемы, это уже глядя с >>> высоты сегодняшнего дня. >>> При этом не факт что это верная интепритация... >>> >>> 1. Работал файл-сервер на FreeBSD 9.2+Samba 4-ка >>> 2. Регулярно (примерно раз в полгода) обновлялся и мир, и порты. >>> 3. Было обновление до 9.3 02.10.2015 >>> 4. 10.12.2015 сервер ушел в бесконечный циклический ребут. >>> 5. Спустя неделю найдена статья на форуме FreeBSD: >>> https://forums.freebsd.org/threads/51470/ >>> >>> Резюме форума: >>> "Same problem here, both 9.3 and 10.1 causes kernel panics under load. >>> FreeBSD 10.2-STABLE fixes this." >>> >>> Попутно было выяснено что у меня похожая ситуация, т.к. разбор логов и >>> транзакций привела к тому, >>> что стало понятно: пользователь упорядочивал (переносил, копировал, >>> удалял, причесывал) весьма большой объем папок (около 350Гб). >>> >>> Из-за чего сервер и дал сбой. >>> >>> Соответственно версия сервера моментально была повышена до 10.2 (порты >>> естественно пересобраны), файловая система проверена. >>> И вроде как проблема была решена. >>> Однако в феврале было мной принято решение написать вопрос в Интернет, >>> т.к. в конце января 2016 начались самопроизвольные перезагрузки >>>сервера. >>> >>> Форум где я это описал >>> http://forum.lissyara.su/viewtopic.php?f=8&t=43816 >>> >>> Также написал на форуме: >>> https://forums.freebsd.org/threads/55123/ >>> >>> Везде советы "колесо пинал, капот открывал"... >>> >>> Написано было письмо в рассылку freedsb-fs >>> >>>https://docs.freebsd.org/mail/archive/2016/freebsd-fs/20160221.freebsd-f >>>s. >>> html >>> >>> Найти глазами: "Re: Kernel panic zio.c, line: 270 FreeBSD 10.2 (or 1" >>> Мне сначала ответил Steven Hartland. >>> >>> Но блин, во первых я не могу писать по англицки такие сложные вопросы. >>> Во-вторых значения, которые он просит, я не могу получить никак. >>> >>> И переписка встала стопором. >>> Нужен кто-то кто может понять мой русский язык. >>> >>> Знаю, что у freebsd по zfs есть русскоязычные разработчики. >>> >>> И в иллюмусе такие тоже есть. Ребята из иллюмуса делают коммиты кода по >>> zfs для freebsd. >>> >>> Дергать их на прямую не знаю как. >>> Пробовал писать слезные письма народу, кто с ними общался - ни ответа, >>>ни >>> привета. >>> >>> На текущий момент начал набирать некую статистику. >>> Мне известно, что косвенным признаком проблемы на объекте (это или >>>файл, >>> или папка) файловой системы является странные права. >>> >>> Т.е. по каким-то причинам отсутствуют групповые дефолтные права >>>(которые >>> всегда обязаны быть): >>> >>> owner@:rwxp--aARWcCos:fd----:allow >>> group@:rwxp--aARWcCos:fd----:allow >>> everyone@:r-x---a-R-c--s:fd----:allow >>> >>> Но этот признак естественно не всегда срабатывает, но в большинстве >>> случаев. >>> есть команда getfacl которая позволяет посмотреть пермишены на файле >>>или >>> папке. >>> >>> Она работает в единичном экземпляре, т.е. не приводит к сбою если >>> смотреть папку или файл. >>> Но попытка собрать оперативно информацию через классическую команду >>> find "some/long/path1" -exec getfacl "{}" \; >>> >>> Вызывает сбой. >>> А это каждый раз: восстанавление системы ~1 час + откат транзакций 2 >>>мин >>> + скрабинг (ресилвинг) массива до консистентного состояния еще порядка >>> 12-17 часов. >>> Поэтому долго искались пути, как все-таки собрать инфо без таких сбоев. >>> Мной был найден способ через утилиту дампинга ZFS под названием zdb >>> Ей надо скормить инод и она покажет техничку по объекту, если объект >>> битый программа zdb фаултится, >>> но система при этом хоть не перезагружается. >>> >>> Был написан составной скрипт суть которого на первом этапе получить все >>> иноды папок и затем поочередно скормить их в zdb. >>> При этом на каждый инод zdb заново загружается. >>> На один инод уходит в среднем 3 секунды. >>> >>> Сбойный инод показывает практически туже информацию, что я уже >>>присылал. >>> >>> Пример: >>> >>> zdb -A -dddddd hdd/usr/wf 7962876 >>> Dataset hdd/usr/wf [ZPL], ID 44, cr_txg 25, 3.79T, 2536954 objects, >>> rootbp DVA[0]=<0:1606c5c7000:3000> DVA[1]=<0:3a1cba7a000:3000> [L0 DMU >>> objset] fletcher4 uncompressed LE contiguous unique double >>>size=800L/800P >>> birth=18957617L/18957617P fill=2536954 >>> cksum=12f0f77640:16477667ed1c:1042ee18bd4db4:8cfeb411f2e56dc >>> >>> Object lvl iblk dblk dsize lsize %full type >>> 7962876 1 16K 512 28.5K 512 100.00 ZFS directory (K=inherit) >>>(Z=inherit) >>> 304 bonus System attributes >>> dnode flags: USED_BYTES USERUSED_ACCOUNTED SPILL_BLKPTR >>> dnode maxblkid: 0 >>> path /_Студия_ГП/МО_Отрадненское ГП/04-ГПМО_ПИ-02/02-Текст >>> uid 10010 >>> gid 10001 >>> atime Fri Mar 4 09:25:04 2016 >>> mtime Mon Feb 8 21:46:51 2016 >>> ctime Fri Feb 19 02:25:26 2016 >>> crtime Thu Dec 10 10:32:40 2015 >>> gen 17690948 >>> mode 40000 >>> size 2 >>> parent 7962875 >>> links 2 >>> pflags 40800000042 >>> Assertion failed: db->db.db_size >= dn->dn_bonuslen (0x0 >= 0x130), >>>file >>> >>>/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com >>>mo >>> n/fs/zfs/dbuf.c, line 339. >>> Assertion failed: (!BP_IS_EMBEDDED(bp) || BPE_GET_ETYPE(bp) == >>> BP_EMBEDDED_TYPE_DATA), file >>> >>>/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com >>>mo >>> n/fs/zfs/arc.c, line 3293. >>> Assertion failed: size > 0 (0x0 > 0x0), file >>> >>>/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com >>>mo >>> n/fs/zfs/arc.c, line 1536. >>> Assertion failed: (bytes > 0), file >>> >>>/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com >>>mo >>> n/fs/zfs/arc.c, line 2789. >>> Assertion failed: c < (1ULL << 24) >> 9 (0x7fffffffffffff < 0x8000), >>>file >>> >>>/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com >>>mo >>> n/fs/zfs/zio.c, line 270. >>> Bus error (core dumped) >>> >>> Как-бы естественным образом подразумевается, что ВСЯ память ECC (24Гб), >>> проверена Memetest86 4.10 (или 4.20, не помню) в режиме ECC - все в >>> порядке. Винчестеры - тоже (сам гонял на MHDD и на стенд возил) ОК. >>> Контроллер перепрошили биос по новее - ничего не изменилось. Провода, >>> коннекторы - тоже ОК. Биос матери тоже перепрошит, сброшен, настроен >>> заново. Без перенастройки биоса проверялось - все тоже самое, сбоит, >>> только все медленно работает. >>> >>> Соответственно на отработку все папок уйдет неделя (несколько недель) >>> непрерывной работы ЕСЛИ не будет сбоев на сервере. >>> Сегодня у меня опять сервер сбоил, и собранная за полторы недели инфо >>> частично безвозвратно пропала. >>> >>> Надо начинать все сначала.Т.к. в таком режиме нет точек останова или >>> паузы... >>> Только когда будут просчитаны все папки имеет смысл браться за файлы. >>> >>> Состояние самого пула : >>> >>> zpool status hdd >>> pool: hdd >>> state: ONLINE >>> status: Some supported features are not enabled on the pool. The pool >>>can >>> still be used, but some features are unavailable. >>> action: Enable all features using 'zpool upgrade'. Once this is done, >>> the pool may no longer be accessible by software that does not >>> support >>> the features. See zpool-features(7) for details. >>> scan: scrub repaired 0 in 11h18m with 0 errors on Fri Feb 19 14:32:49 >>> 2016 >>> config: >>> >>> NAME STATE READ WRITE CKSUM >>> hdd ONLINE 0 0 0 >>> raidz2-0 ONLINE 0 0 0 >>> mfid1p1 ONLINE 0 0 0 >>> mfid2p1 ONLINE 0 0 0 >>> mfid3p1 ONLINE 0 0 0 >>> mfid4p1 ONLINE 0 0 0 >>> mfid5p1 ONLINE 0 0 0 >>> >>> errors: No known data errors >>> >>> Т.е. нормальное... >>> >>> Методов воспроизводства проблемы на другом сервере нет. >>> Отправка пула в другое хранилище не производилась, не проверялась. >>> >>> Но скорее всего приведет к сбою. >>> >>> Последний сбой был 04.03.2016 и он показал, что виной был getfacl на >>> объекте: >>> >>> GNU gdb 6.1.1 [FreeBSD] >>> Copyright 2004 Free Software Foundation, Inc. >>> GDB is free software, covered by the GNU General Public License, and >>>you >>> are >>> welcome to change it and/or distribute copies of it under certain >>> conditions. >>> Type "show copying" to see the conditions. >>> There is absolutely no warranty for GDB. Type "show warranty" for >>>details. >>> This GDB was configured as "amd64-marcel-freebsd"... >>> >>> Unread portion of the kernel message buffer: >>> panic: acl_from_aces: a_type is 0x18 >>> cpuid = 3 >>> KDB: stack backtrace: >>> #0 0xffffffff8099b170 at kdb_backtrace+0x60 >>> #1 0xffffffff8095ed26 at vpanic+0x126 >>> #2 0xffffffff8095ebf3 at panic+0x43 >>> #3 0xffffffff81c1b209 at acl_from_aces+0x1c9 >>> #4 0xffffffff81cd27e6 at zfs_freebsd_getacl+0xa6 >>> #5 0xffffffff80ed5967 at VOP_GETACL_APV+0xa7 >>> #6 0xffffffff809e58cc at vacl_get_acl+0xdc >>> #7 0xffffffff809e57c5 at sys___acl_get_file+0x75 >>> #8 0xffffffff80dab337 at amd64_syscall+0x357 >>> #9 0xffffffff80d90a1b at Xfast_syscall+0xfb >>> Uptime: 3d10h15m29s >>> Dumping 5230 out of 24542 >>> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >>> >>> Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. >>> Loaded symbols for /boot/kernel/if_lagg.ko.symbols >>> Reading symbols from /boot/kernel/aio.ko.symbols...done. >>> Loaded symbols for /boot/kernel/aio.ko.symbols >>> Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. >>> Loaded symbols for /boot/kernel/ichsmb.ko.symbols >>> Reading symbols from /boot/kernel/ipmi.ko.symbols...done. >>> Loaded symbols for /boot/kernel/ipmi.ko.symbols >>> Reading symbols from /boot/kernel/zfs.ko.symbols...done. >>> Loaded symbols for /boot/kernel/zfs.ko.symbols >>> Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. >>> Loaded symbols for /boot/kernel/opensolaris.ko.symbols >>> Reading symbols from /boot/kernel/ums.ko.symbols...done. >>> Loaded symbols for /boot/kernel/ums.ko.symbols >>> Reading symbols from /boot/kernel/smbfs.ko.symbols...done. >>> Loaded symbols for /boot/kernel/smbfs.ko.symbols >>> Reading symbols from /boot/kernel/libiconv.ko.symbols...done. >>> Loaded symbols for /boot/kernel/libiconv.ko.symbols >>> Reading symbols from /boot/kernel/libmchain.ko.symbols...done. >>> Loaded symbols for /boot/kernel/libmchain.ko.symbols >>> #0 doadump (textdump=<value optimized out>) at pcpu.h:219 >>> 219 pcpu.h: No such file or directory. >>> in pcpu.h >>> >>> (kgdb) bt full >>> #0 doadump (textdump=<value optimized out>) at pcpu.h:219 >>> No locals. >>> #1 0xffffffff8095e982 in kern_reboot (howto=260) at >>> /usr/src/sys/kern/kern_shutdown.c:451 >>> No locals. >>> #2 0xffffffff8095ed65 in vpanic (fmt=<value optimized out>, ap=<value >>> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:758 >>> buf = "acl_from_aces: a_type is 0x18", '\0' <repeats 226 times> >>> td = <value optimized out> >>> newpanic = <value optimized out> >>> bootopt = <value optimized out> >>> #3 0xffffffff8095ebf3 in panic (fmt=0x0) at >>> /usr/src/sys/kern/kern_shutdown.c:687 >>> ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = >>> 0xfffffe06789ad700, reg_save_area = 0xfffffe06789ad6a0}} >>> #4 0xffffffff81c1b209 in acl_from_aces (aclp=<value optimized out>, >>> aces=<value optimized out>, nentries=<value optimized out>) >>> at >>> >>>/usr/src/sys/modules/zfs/../../cddl/compat/opensolaris/kern/opensolaris_ >>>ac >>> l.c:164 >>> entry = <value optimized out> >>> #5 0xffffffff81cd27e6 in zfs_freebsd_getacl (ap=0xfffffe06789ad7e0) >>> at >>> >>>/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zf >>>s/ >>> zfs_vnops.c:7028 >>> vsecattr = {vsa_mask = 48, vsa_aclcnt = 10, vsa_aclentp = >>> 0xfffff803af731180, vsa_dfaclcnt = 525312, vsa_dfaclentp = 0xff, >>> vsa_aclentsz = 120, vsa_aclflags = 2023413696} >>> error = <value optimized out> >>> #6 0xffffffff80ed5967 in VOP_GETACL_APV (vop=<value optimized out>, >>> a=<value optimized out>) at vnode_if.c:2927 >>> mp__ = <value optimized out> >>> rc = <value optimized out> >>> #7 0xffffffff809e58cc in vacl_get_acl (td=0xfffff8033c2704a0, >>> vp=0xfffff805d9577000, type=4, aclp=0x813506000) at vnode_if.h:1221 >>> error = <value optimized out> >>> inkernelacl = <value optimized out> >>> #8 0xffffffff809e57c5 in sys___acl_get_file (td=0xfffff8033c2704a0, >>> uap=0xfffffe06789adb80) at /usr/src/sys/kern/vfs_acl.c:339 >>> nd = {ni_dirp = 0x813515c70 <Address 0x813515c70 out of >>>bounds>, >>> ni_segflg = UIO_USERSPACE, ni_rightsneeded = {cr_rights = { >>> 144115188075855872, 288230376151711744}}, ni_startdir = 0x0, >>> ni_rootdir = 0xfffff8009089db10, ni_topdir = 0x0, ni_dirfd = -100, >>> ni_strictrelative = 0, ni_filecaps = {fc_rights = {cr_rights = {0, >>>0}}, >>> fc_ioctls = 0x0, fc_nioctls = -1, fc_fcntls = 0}, >>> ni_vp = 0xfffff805d9577000, ni_dvp = 0xfffff805d9b72760, ni_pathlen = >>> 1, ni_next = 0xfffff80528980c73 "", ni_loopcnt = 0, ni_cnd = { >>> cn_nameiop = 0, cn_flags = 49216, cn_thread = 0xfffff8033c2704a0, >>> cn_cred = 0xfffff80173fa9c00, cn_lkflags = 2097152, >>> cn_pnbuf = 0xfffff80528980c00 >>> "_С▒\202▒\203ди▒\217_▒\223▒\237/▒\234▒\236_▒\236▒\202▒\200аднен▒\201кое >>> >>>▒\223▒\237/04-▒\223▒\237▒\234▒\236_▒\237▒\230-02/05-▒\224ок▒\203мен▒\202 >>>▒\ >>> 213/01-▒\232он▒\202▒\200ак▒\202", >>> cn_nameptr = 0xfffff80528980c60 "01-▒\232он▒\202▒\200ак▒\202", >>> cn_namelen = 19, cn_consume = 0}} >>> error = <value optimized out> >>> #9 0xffffffff80dab337 in amd64_syscall (td=0xfffff8033c2704a0, >>>traced=0) >>> at subr_syscall.c:134 >>> sa = {code = 347, callp = 0xffffffff814f70a0, args = >>> {34683837552, 4, 34683772928, 0, 4096, 100725, 1, -8782198930272}, >>> narg = 3} >>> ksi = {ksi_link = {tqe_next = 0xfffffe06789adb60, tqe_prev = >>> 0xffffffff80e92163}, ksi_info = {si_signo = 1, si_errno = 0, >>> si_code = -17128, si_pid = 0, si_uid = 3380582272, si_status = >>>-506, >>> si_addr = 0xfffffe06c97f9780, si_value = { >>> sival_int = -914385024, sival_ptr = 0xfffffe06c97f9780, >>>sigval_int >>> = -914385024, sigval_ptr = 0xfffffe06c97f9780}, _reason = { >>> ---Type <return> to continue, or q <return> to quit--- >>> _fault = {_trapno = 1255550392}, _timer = {_timerid = 1255550392, >>> _overrun = -506}, _mesgq = {_mqd = 1255550392}, _poll = { >>> _band = -2171997901384}, __spare__ = {__spare1__ = >>> -2171997901384, __spare2__ = {-2123695504, -1, 16982108, 0, 1177625731, >>> 296129, 1255550336}}}}, ksi_flags = 2023414720, ksi_sigq = >>> 0xffffffff80e928b8} >>> error = <value optimized out> >>> #10 0xffffffff80d90a1b in Xfast_syscall () at >>> /usr/src/sys/amd64/amd64/exception.S:396 >>> No locals. >>> #11 0x000000080556d19a in ?? () >>> No symbol table info available. >>> Previous frame inner to this frame (corrupt stack?) >>> Current language: auto; currently minimal >>> (kgdb) p bp >>> No symbol "bp" in current context. >>> (kgdb) p bp* >>> >>> Опять-же новый (после мартовского сбоя) zpool status hdd >>> pool: hdd >>> state: ONLINE >>> status: Some supported features are not enabled on the pool. The pool >>>can >>> still be used, but some features are unavailable. >>> action: Enable all features using 'zpool upgrade'. Once this is done, >>> the pool may no longer be accessible by software that does not >>> support >>> the features. See zpool-features(7) for details. >>> scan: scrub repaired 0 in 15h19m with 0 errors on Thu Mar 10 08:01:46 >>> 2016 >>> config: >>> >>> NAME STATE READ WRITE CKSUM >>> hdd ONLINE 0 0 0 >>> raidz2-0 ONLINE 0 0 0 >>> mfid1p1 ONLINE 0 0 0 >>> mfid2p1 ONLINE 0 0 0 >>> mfid3p1 ONLINE 0 0 0 >>> mfid4p1 ONLINE 0 0 0 >>> mfid5p1 ONLINE 0 0 0 >>> >>> errors: No known data errors >>> >>> ====================================================== >>> Конец цитаты. >>> >>> Можете подсказать куда двигаться дальше? >>> >>> С уважением, >>> и почти без надежды... >>> >>> С уважением, >>> Руслан Л. Викулов ------------------------------------------- openzfs-developer Archives: https://www.listbox.com/member/archive/274414/=now RSS Feed: https://www.listbox.com/member/archive/rss/274414/28015062-cce53afa Modify Your Subscription: https://www.listbox.com/member/?member_id=28015062&id_secret=28015062-f966d51c Powered by Listbox: http://www.listbox.com
