Re: SAS hotswap и баг
artiom -> debian-russian@lists.debian.org @ Sun, 8 Apr 2018 16:55:12 +0300: >> > Вытащил диск, вставил на место, но в /dev его не увидел. >> > Зато увидел вот это в dmesg: >> >> Это там, где ZFS поверх LUKS? Есть шанс, что ты получил ответ на свой >> вопрос, что же ты сделал неправильно. >> > Вряд ли тут что-то неправильно. > Да и шанса такого нет. > scsi_device_dev_release_usercontext явно знать не может о каком-то LUKS. Ну, насчет шанса нет я бы не был так уверен. Нынче в ядре у нас что ни блоковое устройство, то SCSI, даже если оно чисто программное. Хотя, если в /dev нет самого диска, то в общем, да, говорить о проблеме в районе LUKS не следует. Если проблема там, то нижележащий диск должен быть на месте. >> > [69497.081559] sd 0:0:5:0: [sdf] Synchronize Cache(10) failed: Result: >> > hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK >> > [69916.705257] Buffer I/O error on dev dm-8, logical block 0, async page >> read >> > [69930.896113] list_del corruption, 986c0632b010->next is >> LIST_POISON1 (dead0100) >> > [69930.896226] [ cut here ] >> > [69930.896227] kernel BUG at >> /build/linux-3RM5ap/linux-4.14.13/lib/list_debug.c:47! >> > [69930.896329] invalid opcode: [#1] SMP PTI >> > [69930.896416] Modules linked in: xt_nat veth ipt_MASQUERADE >> > nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo >> > iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype >> > xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc bonding >> xt_tcpudp >> > cpufreq_conservative cpufreq_userspace cpufreq_powersave iptable_filter >> > intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt >> > iTCO_vendor_support kvm irqbypass ttm drm_kms_helper intel_cstate >> intel_uncore >> > pcspkr intel_rapl_perf serio_raw drm evdev mei_me mei sg lpc_ich mfd_core >> > shpchp ie31200_edac button nuvoton_cir ipmi_si battery ipmi_devintf >> rc_core >> > ipmi_msghandler tpm_crb video acpi_pad nct6775 hwmon_vid jc42 coretemp >> > ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) >> zcommon(PO) >> > znvpair(PO) >> > [69930.896925] spl(O) btrfs zstd_decompress zstd_compress xxhash >> > algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov >> > async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c >> crc32c_generic >> > raid1 raid0 multipath linear md_mod sd_mod hid_generic usbhid hid >> > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc >> > aesni_intel aes_x86_64 crypto_simd ahci glue_helper xhci_pci cryptd >> libahci >> > mpt3sas igb xhci_hcd raid_class i2c_algo_bit libata scsi_transport_sas >> dca >> > i2c_i801 ptp pps_core usbcore scsi_mod usb_common fan thermal >> > [69930.897315] CPU: 7 PID: 15570 Comm: kworker/u16:2 Tainted: P O >> > 4.14.0-0.bpo.3-amd64 #1 Debian 4.14.13-1~bpo9+1 >> > [69930.897462] Hardware name: To Be Filled By O.E.M. To Be Filled By >> > O.E.M./E3C224D4I-14S, BIOS P3.20 05/29/2015 >> > [69930.897612] Workqueue: fw_event_mpt2sas0 _firmware_event_work >> [mpt3sas] >> > [69930.897732] task: 986a138af040 task.stack: bbcfca9a8000 >> > [69930.897846] RIP: 0010:__list_del_entry_valid+0x4e/0x90 >> > [69930.897958] RSP: 0018:bbcfca9abb48 EFLAGS: 00010086 >> > [69930.898070] RAX: 004e RBX: 0246 RCX: >> >> > [69930.898185] RDX: RSI: 986c1fdd66f8 RDI: >> 986c1fdd66f8 >> > [69930.898298] RBP: 986c0632b738 R08: R09: >> 0fdf >> > [69930.898413] R10: 017d R11: 99b88e6d R12: >> 986c0636b180 >> > [69930.898527] R13: 986c05f22000 R14: 986c0632b000 R15: >> 986c0d078010 >> > [69930.898641] FS: () GS:986c1fdc() >> knlGS: >> > [69930.898779] CS: 0010 DS: ES: CR0: 80050033 >> > [69930.898892] CR2: 7fbe5e9f4ab4 CR3: 00019b40a005 CR4: >> 001606e0 >> > [69930.899008] Call Trace: >> > [69930.899121] scsi_device_dev_release_usercontext+0x55/0x260 [scsi_mod] >> > [69930.899242] execute_in_process_context+0x5e/0x70 >> > [69930.899358] device_release+0x2d/0x80 >> > [69930.899467] kobject_put+0xa5/0x1a0 >> > [69930.899580] scsi_remove_target+0x171/0x1b0 [scsi_mod] >> > [69930.899699] sas_rphy_remove+0x55/0x60 [scsi_transport_sas] >> > [69930.899814] sas_port_delete+0x2a/0x160 [scsi_transport_sas] >> > [69930.899931] mpt3sas_transport_port_remove+0x1bc/0x220 [mpt3sas] >> > [69930.900053] _scsih_remove_device+0x21d/0x330 [mpt3sas] >> > [69930.900171] ? _scsih_sas_host_refresh+0x118/0x180 [mpt3sas] >> > [69930.900290] _scsih_device_remove_by_handle.part.30+0x78/0xc0 >> [mpt3sas] >> > [69930.900407] _firmware_event_work+0x15c7/0x1d80 [mpt3sas] >> > [69930.900519] ? update_curr+0xf0/0x1a0 >>
Re: SAS hotswap и баг
На ядро апстрима на NAS я точно не буду переключаться. 08.04.2018 15:39, Alexander Gerasiov пишет: > Hello Артём, > > On Sun, 8 Apr 2018 11:37:14 +0300 > Артём Н. wrote: > >> Вытащил диск, вставил на место, но в /dev его не увидел. >> Зато увидел вот это в dmesg: >> >> [69497.081559] sd 0:0:5:0: [sdf] Synchronize Cache(10) failed: >> Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [69916.705257] >> Buffer I/O error on dev dm-8, logical block 0, async page read >> [69930.896113] list_del corruption, 986c0632b010->next is >> LIST_POISON1 (dead0100) [69930.896226] [ cut here > >> >> >> Чтобы это могло быть? > > Судя по трейсу, сработал ассерт в scsi_mod. Имеет смысл запостить этот > трейс в профильный список рассылки. Вначале проверив, что он > вопроизводится, затем проверив, что он воспроизводится на последней > версии твоего ядра (потому что у тебя 4.14.13, а у апстрима уже > 4.14.32). >
Re: SAS hotswap и баг
08.04.2018 12:44, Artem Chuprina пишет: > Артём Н. -> debian-russian@lists.debian.org @ Sun, 8 Apr 2018 11:37:14 +0300: > > > Вытащил диск, вставил на место, но в /dev его не увидел. > > Зато увидел вот это в dmesg: > > Это там, где ZFS поверх LUKS? Есть шанс, что ты получил ответ на свой > вопрос, что же ты сделал неправильно. > Вряд ли тут что-то неправильно. Да и шанса такого нет. scsi_device_dev_release_usercontext явно знать не может о каком-то LUKS. > > [69497.081559] sd 0:0:5:0: [sdf] Synchronize Cache(10) failed: Result: > > hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK > > [69916.705257] Buffer I/O error on dev dm-8, logical block 0, async page > read > > [69930.896113] list_del corruption, 986c0632b010->next is LIST_POISON1 > (dead0100) > > [69930.896226] [ cut here ] > > [69930.896227] kernel BUG at > /build/linux-3RM5ap/linux-4.14.13/lib/list_debug.c:47! > > [69930.896329] invalid opcode: [#1] SMP PTI > > [69930.896416] Modules linked in: xt_nat veth ipt_MASQUERADE > > nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo > > iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype > > xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc bonding > xt_tcpudp > > cpufreq_conservative cpufreq_userspace cpufreq_powersave iptable_filter > > intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt > > iTCO_vendor_support kvm irqbypass ttm drm_kms_helper intel_cstate > intel_uncore > > pcspkr intel_rapl_perf serio_raw drm evdev mei_me mei sg lpc_ich mfd_core > > shpchp ie31200_edac button nuvoton_cir ipmi_si battery ipmi_devintf rc_core > > ipmi_msghandler tpm_crb video acpi_pad nct6775 hwmon_vid jc42 coretemp > > ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) > zcommon(PO) > > znvpair(PO) > > [69930.896925] spl(O) btrfs zstd_decompress zstd_compress xxhash > > algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov > > async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c > crc32c_generic > > raid1 raid0 multipath linear md_mod sd_mod hid_generic usbhid hid > > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc > > aesni_intel aes_x86_64 crypto_simd ahci glue_helper xhci_pci cryptd libahci > > mpt3sas igb xhci_hcd raid_class i2c_algo_bit libata scsi_transport_sas dca > > i2c_i801 ptp pps_core usbcore scsi_mod usb_common fan thermal > > [69930.897315] CPU: 7 PID: 15570 Comm: kworker/u16:2 Tainted: P O > > 4.14.0-0.bpo.3-amd64 #1 Debian 4.14.13-1~bpo9+1 > > [69930.897462] Hardware name: To Be Filled By O.E.M. To Be Filled By > > O.E.M./E3C224D4I-14S, BIOS P3.20 05/29/2015 > > [69930.897612] Workqueue: fw_event_mpt2sas0 _firmware_event_work [mpt3sas] > > [69930.897732] task: 986a138af040 task.stack: bbcfca9a8000 > > [69930.897846] RIP: 0010:__list_del_entry_valid+0x4e/0x90 > > [69930.897958] RSP: 0018:bbcfca9abb48 EFLAGS: 00010086 > > [69930.898070] RAX: 004e RBX: 0246 RCX: > > > [69930.898185] RDX: RSI: 986c1fdd66f8 RDI: > 986c1fdd66f8 > > [69930.898298] RBP: 986c0632b738 R08: R09: > 0fdf > > [69930.898413] R10: 017d R11: 99b88e6d R12: > 986c0636b180 > > [69930.898527] R13: 986c05f22000 R14: 986c0632b000 R15: > 986c0d078010 > > [69930.898641] FS: () GS:986c1fdc() > knlGS: > > [69930.898779] CS: 0010 DS: ES: CR0: 80050033 > > [69930.898892] CR2: 7fbe5e9f4ab4 CR3: 00019b40a005 CR4: > 001606e0 > > [69930.899008] Call Trace: > > [69930.899121] scsi_device_dev_release_usercontext+0x55/0x260 [scsi_mod] > > [69930.899242] execute_in_process_context+0x5e/0x70 > > [69930.899358] device_release+0x2d/0x80 > > [69930.899467] kobject_put+0xa5/0x1a0 > > [69930.899580] scsi_remove_target+0x171/0x1b0 [scsi_mod] > > [69930.899699] sas_rphy_remove+0x55/0x60 [scsi_transport_sas] > > [69930.899814] sas_port_delete+0x2a/0x160 [scsi_transport_sas] > > [69930.899931] mpt3sas_transport_port_remove+0x1bc/0x220 [mpt3sas] > > [69930.900053] _scsih_remove_device+0x21d/0x330 [mpt3sas] > > [69930.900171] ? _scsih_sas_host_refresh+0x118/0x180 [mpt3sas] > > [69930.900290] _scsih_device_remove_by_handle.part.30+0x78/0xc0 [mpt3sas] > > [69930.900407] _firmware_event_work+0x15c7/0x1d80 [mpt3sas] > > [69930.900519] ? update_curr+0xf0/0x1a0 > > [69930.900627] ? pick_next_task_fair+0x156/0x570 > > [69930.900737] ? __switch_to+0xa8/0x450 > > [69930.900844] process_one_work+0x181/0x370 > > [69930.900953] worker_thread+0x4d/0x3c0 > > [69930.901061] kthread+0xfc/0x130 > > [69930.901168] ? process_one_work+0x370/0x370 > > [69930.901278] ? kthread_create_on_node+0x70/0x70 > > [69930.901388] ret_from_fork+0x1f/0x30 > > [69930.901494] Code: 74 2b 48 8b 12 48 39 d
Re: SAS hotswap и баг
Hello Артём, On Sun, 8 Apr 2018 11:37:14 +0300 Артём Н. wrote: > Вытащил диск, вставил на место, но в /dev его не увидел. > Зато увидел вот это в dmesg: > > [69497.081559] sd 0:0:5:0: [sdf] Synchronize Cache(10) failed: > Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [69916.705257] > Buffer I/O error on dev dm-8, logical block 0, async page read > [69930.896113] list_del corruption, 986c0632b010->next is > LIST_POISON1 (dead0100) [69930.896226] [ cut here > > > Чтобы это могло быть? Судя по трейсу, сработал ассерт в scsi_mod. Имеет смысл запостить этот трейс в профильный список рассылки. Вначале проверив, что он вопроизводится, затем проверив, что он воспроизводится на последней версии твоего ядра (потому что у тебя 4.14.13, а у апстрима уже 4.14.32). -- Best regards, Alexander Gerasiov Contacts: e-mail: g...@cs.msu.su WWW: http://gerasiov.net TG/Skype: gerasiov PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1
Re: SAS hotswap и баг
Артём Н. -> debian-russian@lists.debian.org @ Sun, 8 Apr 2018 11:37:14 +0300: > Вытащил диск, вставил на место, но в /dev его не увидел. > Зато увидел вот это в dmesg: Это там, где ZFS поверх LUKS? Есть шанс, что ты получил ответ на свой вопрос, что же ты сделал неправильно. > [69497.081559] sd 0:0:5:0: [sdf] Synchronize Cache(10) failed: Result: > hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK > [69916.705257] Buffer I/O error on dev dm-8, logical block 0, async page read > [69930.896113] list_del corruption, 986c0632b010->next is LIST_POISON1 > (dead0100) > [69930.896226] [ cut here ] > [69930.896227] kernel BUG at > /build/linux-3RM5ap/linux-4.14.13/lib/list_debug.c:47! > [69930.896329] invalid opcode: [#1] SMP PTI > [69930.896416] Modules linked in: xt_nat veth ipt_MASQUERADE > nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo > iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype > xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc bonding > xt_tcpudp > cpufreq_conservative cpufreq_userspace cpufreq_powersave iptable_filter > intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt > iTCO_vendor_support kvm irqbypass ttm drm_kms_helper intel_cstate > intel_uncore > pcspkr intel_rapl_perf serio_raw drm evdev mei_me mei sg lpc_ich mfd_core > shpchp ie31200_edac button nuvoton_cir ipmi_si battery ipmi_devintf rc_core > ipmi_msghandler tpm_crb video acpi_pad nct6775 hwmon_vid jc42 coretemp > ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) zcommon(PO) > znvpair(PO) > [69930.896925] spl(O) btrfs zstd_decompress zstd_compress xxhash > algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov > async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c > crc32c_generic > raid1 raid0 multipath linear md_mod sd_mod hid_generic usbhid hid > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc > aesni_intel aes_x86_64 crypto_simd ahci glue_helper xhci_pci cryptd libahci > mpt3sas igb xhci_hcd raid_class i2c_algo_bit libata scsi_transport_sas dca > i2c_i801 ptp pps_core usbcore scsi_mod usb_common fan thermal > [69930.897315] CPU: 7 PID: 15570 Comm: kworker/u16:2 Tainted: P O > 4.14.0-0.bpo.3-amd64 #1 Debian 4.14.13-1~bpo9+1 > [69930.897462] Hardware name: To Be Filled By O.E.M. To Be Filled By > O.E.M./E3C224D4I-14S, BIOS P3.20 05/29/2015 > [69930.897612] Workqueue: fw_event_mpt2sas0 _firmware_event_work [mpt3sas] > [69930.897732] task: 986a138af040 task.stack: bbcfca9a8000 > [69930.897846] RIP: 0010:__list_del_entry_valid+0x4e/0x90 > [69930.897958] RSP: 0018:bbcfca9abb48 EFLAGS: 00010086 > [69930.898070] RAX: 004e RBX: 0246 RCX: > > [69930.898185] RDX: RSI: 986c1fdd66f8 RDI: > 986c1fdd66f8 > [69930.898298] RBP: 986c0632b738 R08: R09: > 0fdf > [69930.898413] R10: 017d R11: 99b88e6d R12: > 986c0636b180 > [69930.898527] R13: 986c05f22000 R14: 986c0632b000 R15: > 986c0d078010 > [69930.898641] FS: () GS:986c1fdc() > knlGS: > [69930.898779] CS: 0010 DS: ES: CR0: 80050033 > [69930.898892] CR2: 7fbe5e9f4ab4 CR3: 00019b40a005 CR4: > 001606e0 > [69930.899008] Call Trace: > [69930.899121] scsi_device_dev_release_usercontext+0x55/0x260 [scsi_mod] > [69930.899242] execute_in_process_context+0x5e/0x70 > [69930.899358] device_release+0x2d/0x80 > [69930.899467] kobject_put+0xa5/0x1a0 > [69930.899580] scsi_remove_target+0x171/0x1b0 [scsi_mod] > [69930.899699] sas_rphy_remove+0x55/0x60 [scsi_transport_sas] > [69930.899814] sas_port_delete+0x2a/0x160 [scsi_transport_sas] > [69930.899931] mpt3sas_transport_port_remove+0x1bc/0x220 [mpt3sas] > [69930.900053] _scsih_remove_device+0x21d/0x330 [mpt3sas] > [69930.900171] ? _scsih_sas_host_refresh+0x118/0x180 [mpt3sas] > [69930.900290] _scsih_device_remove_by_handle.part.30+0x78/0xc0 [mpt3sas] > [69930.900407] _firmware_event_work+0x15c7/0x1d80 [mpt3sas] > [69930.900519] ? update_curr+0xf0/0x1a0 > [69930.900627] ? pick_next_task_fair+0x156/0x570 > [69930.900737] ? __switch_to+0xa8/0x450 > [69930.900844] process_one_work+0x181/0x370 > [69930.900953] worker_thread+0x4d/0x3c0 > [69930.901061] kthread+0xfc/0x130 > [69930.901168] ? process_one_work+0x370/0x370 > [69930.901278] ? kthread_create_on_node+0x70/0x70 > [69930.901388] ret_from_fork+0x1f/0x30 > [69930.901494] Code: 74 2b 48 8b 12 48 39 d7 75 34 48 8b 50 08 48 39 d7 75 3c > b8 01 00 00 00 c3 48 89 fe 48 89 c2 48 c7 c7 60 9e 44 99 e8 7d 21 d5 ff <0f> > 0b 48 89 fe 48 c7 c7 98 9e 44 99 e8 6c 21 d5 ff 0f 0b 48 89 > [69930.901702] RIP: __list_del_entry_valid+0x4e/0x90 RSP: bbcfca9abb48 > [69930.901816] ---[ end trace b1b41653fc7fb543 ]---
Re: Системы управления сервером?
artiom -> debian-russian@lists.debian.org @ Sun, 8 Apr 2018 11:55:37 +0300: >> Ну, еще регулярно лезут подобные баги в криптопротоколах, но там вот как >> раз сотни, а то и тысячи ревью, а толку? Потом лет через 10-15 таки >> находится тысяча первый ревьюер, который таки замечает багу и делает >> эксплойт. >> > Может быть из-за ревью он находится через 10-15 лет, а не каждый год на > их протяжении? И это тоже, но это ревью, опять же, в духе байки про Боинг, и задолго до начала реализации. А баги в реализации обычно ловят тесты. >> А обычно бага либо легко правится, либо быстро замечается. В идеале и >> то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе >> реализации фичи, но так бывает не всегда :) >> > Угу, 50% времени на тесты в TDD, которые также могут баги содержать, о > чём как-то давно вы сами и писали. Если считать только время реализации, отдельно от размышлений об архитектуре, то больше 50%. На глазок, примерно 70. Оно, правда, часто окупается. >> >> >> >> Практика показывает, что читать код _до_ попадания в >> репозиторий - не >> >> >> >> очень хорошая идея. Благо репозиторий позволяет, если что, >> откатить. >> >> >> >> >> >> >> > Но сборки уже будут собраны и отправлены на тестирование, так не >> лучше >> >> >> > ли - не допустить? >> >> >> > Какая практика? >> >> >> > В чём нехорошесть данной идеи? >> >> >> >> >> >> Тормозной путь. Между моментом изменения кода и моментом, когда код >> >> >> будет изменен, проходит время. >> >> > Как минус, так и плюс. >> >> >> >> В течение этого времени в системе присутствуют и старые, и новые баги. >> >> Где плюс? >> >> >> > Нет, присутствуют только старые баги, которые уже известны, проверены и >> > одеты в пиджак, так что стали напоминать фичи. >> >> В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И >> поверх них уже идет работа. >> > Да не идёт поверх них работы, пока их нет в репозитории, иначе процесс > неверно построен. То есть в верно построенном процессе эти два дня никто ничего не делает ни в чем, завязанном на это место кода? Верно построен процесс, что и говорить... >> И не факт, кстати, что старые баги известны. Мы можем говорить о ревью, >> например, фикса свеженаступленной грабли. Она, может, в коде и пару лет >> уже, но важный заказчик наступил на нее только сегодня, а до него просто >> никому не приходило в голову проделать именно эту последовательность >> действий. >> > Главное, чтобы фикс не внёс два других ещё более неочевидных бага и > ничего не сломал. А это по коду фикса очень трудно понять. Нужен контекст гораздо большего объема. Тут как раз набор автоматизированных тестов работает не в пример лучше - в нем этот контекст зафиксирован. >> > А тут новые баги, которые успеют сломать тестирование, например, в >> > результате чего могут не пройти другие тесты и т.п.. >> > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты, >> > однако есть факты на практике). >> >> На практике тесты для того и существуют, чтобы баги их ломали. Один фиг, >> если тест сломался, то багу надо чинить. Если бага сломала сразу много >> тестов, починка приоритетна, и все дела. >> > Ладно, умолчу про тех, кто "чинит" тесты в таком случае. > Такие тоже бывали. > Но очень редко тестовое покрытие полное. Практически никогда. Но требуется не полнота, а хорошая вероятность вылавливания баги раньше, чем на нее наступит заказчик. >> >> > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и >> >> > ждать ответов автора (который в этом время уже над другим работает), >> к >> >> > тому же, ревьюверов бывает несколько. >> >> >> >> Я про прерывания не процесса ревью, а про прерывания процесса своей >> >> работы необходимостью ревью. Для ревью надо загрузить в голову контекст >> >> той задачи, к которой относится просматриваемый код. Он там неизбежно >> >> заменит контекст своей задачи. После ревью придется снова грузить свой. >> >> Это время, и в случае сложной задачи весьма изрядное. От 15 минут до >> >> часа каждая перегрузка, а их тут две. >> > Ну час - это явный перебор. >> >> Это значит, у тебя все задачи простые. >> > Не сказал бы. Ревью компактные относительно. И, естественно, что я не > вникаю в весь код: только в изменения. То есть как раз неочевидные грабли, которые вносит изменение, ты пропустишь с вероятностью, близкой к 1. >> > А отрыв на 15 минут - не критично: вы же не соревновательным >> > программированием занимаетесь, надеюсь? >> >> Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в >> контекст. >> > Есть вечер, утро и обед, если не критично. В обед надо обедать. И мозгом тоже. Иначе очень быстро огребешь гастрит. >> > Иногда вообще полезно от задачи оторваться, бывает. >> >> В моем опыте оторваться от задачи полезно, а вот заменять в голове ее >> контекст контекстом другой задачи как раз вред
Re: Нюансы взаимодействия ZFS
02.04.2018 14:17, Dmitry Kulagin пишет: >> Отсюда вывод: всё-таки несмотря на "заверения экспертов" располагать ZFS >> pool лучше поверх LUKS, а не наоборот. >> LUKS почти не вносит оверхед. >> А кэширование записи диска всегда возможно включить вручную (как и >> подобрать размер блока, который у ZFS, к тому же, переменный). >> > А после этого возникает закономерный вопрос: а зачем вам zfs? > Вы только что избавились от одного из самых больших плюсов zfs и > начали работать с device mapper, ну так продолжайте с ним работать, > lvm и вперед, зачем плодить сущности? > Кстати, их стало меньше: LVM и ФС теперь нет.
Re: Системы управления сервером?
> > Есть минусы, есть плюсы: не так легко откатить сломавшую правку из > > репозитория, на которую уже понакоммитили и заложили функционал. > > Бывает и такое. Но мне в жизни всего однажды встретилась грабля, которую > очень не сразу удалось обнаружить, не брали никакие разумные тесты, и > трудоемко было потом починить. Так и не починили, кстати. Причем по > крайней мере два первых ревью (два разных человека, входивших в разное > время в проект, внимательно читали этот код) она тоже успешно > проскочила. > Ну да, бывает. > Ну, еще регулярно лезут подобные баги в криптопротоколах, но там вот как > раз сотни, а то и тысячи ревью, а толку? Потом лет через 10-15 таки > находится тысяча первый ревьюер, который таки замечает багу и делает > эксплойт. > Может быть из-за ревью он находится через 10-15 лет, а не каждый год на их протяжении? > А обычно бага либо легко правится, либо быстро замечается. В идеале и > то, и другое. Совсем в идеале ее ловит юнит-тест еще в процессе > реализации фичи, но так бывает не всегда :) > Угу, 50% времени на тесты в TDD, которые также могут баги содержать, о чём как-то давно вы сами и писали. > >> >> >> Практика показывает, что читать код _до_ попадания в репозиторий > - не > >> >> >> очень хорошая идея. Благо репозиторий позволяет, если что, > откатить. > >> >> >> > >> >> > Но сборки уже будут собраны и отправлены на тестирование, так не > лучше > >> >> > ли - не допустить? > >> >> > Какая практика? > >> >> > В чём нехорошесть данной идеи? > >> >> > >> >> Тормозной путь. Между моментом изменения кода и моментом, когда код > >> >> будет изменен, проходит время. > >> > Как минус, так и плюс. > >> > >> В течение этого времени в системе присутствуют и старые, и новые баги. > >> Где плюс? > >> > > Нет, присутствуют только старые баги, которые уже известны, проверены и > > одеты в пиджак, так что стали напоминать фичи. > > В коде они уже есть. В репозиторий еще не попали, а в коде уже есть. И > поверх них уже идет работа. > Да не идёт поверх них работы, пока их нет в репозитории, иначе процесс неверно построен. > И не факт, кстати, что старые баги известны. Мы можем говорить о ревью, > например, фикса свеженаступленной грабли. Она, может, в коде и пару лет > уже, но важный заказчик наступил на нее только сегодня, а до него просто > никому не приходило в голову проделать именно эту последовательность > действий. > Главное, чтобы фикс не внёс два других ещё более неочевидных бага и ничего не сломал. > > А тут новые баги, которые успеют сломать тестирование, например, в > > результате чего могут не пройти другие тесты и т.п.. > > На ревью есть шанс хоть что-то отсеять (да, я в курсе про юнит-тесты, > > однако есть факты на практике). > > На практике тесты для того и существуют, чтобы баги их ломали. Один фиг, > если тест сломался, то багу надо чинить. Если бага сломала сразу много > тестов, починка приоритетна, и все дела. > Ладно, умолчу про тех, кто "чинит" тесты в таком случае. Такие тоже бывали. Но очень редко тестовое покрытие полное. > >> > Да, с прерываниями. Но сложно постоянно концентрироваться на ревью и > >> > ждать ответов автора (который в этом время уже над другим работает), к > >> > тому же, ревьюверов бывает несколько. > >> > >> Я про прерывания не процесса ревью, а про прерывания процесса своей > >> работы необходимостью ревью. Для ревью надо загрузить в голову контекст > >> той задачи, к которой относится просматриваемый код. Он там неизбежно > >> заменит контекст своей задачи. После ревью придется снова грузить свой. > >> Это время, и в случае сложной задачи весьма изрядное. От 15 минут до > >> часа каждая перегрузка, а их тут две. > > Ну час - это явный перебор. > > Это значит, у тебя все задачи простые. > Не сказал бы. Ревью компактные относительно. И, естественно, что я не вникаю в весь код: только в изменения. А задача делается не один день. Я её помню и хотя бы иногда надо отвлекаться. > > А отрыв на 15 минут - не критично: вы же не соревновательным > > программированием занимаетесь, надеюсь? > > Каждая перезагрузка. Каждое ревью. Плюс столько же потом вернуться в контекст. > Есть вечер, утро и обед, если не критично. Обычно срочно закрывать не приходится. Вполне себе нормальный способ оторваться от задачи. > > Иногда вообще полезно от задачи оторваться, бывает. > > В моем опыте оторваться от задачи полезно, а вот заменять в голове ее > контекст контекстом другой задачи как раз вредно. Ну да люди разные, > задачи тоже. > Ну это возможно. Просто обычно на ревью "отдыхаешь". Хотя... > > Другое дело, если ревью много. Тогда да, на них забивают. > > И это, кстати, тоже. Не написанный тест ловится хотя бы coverage, а > забитое ревью от выполненного без претензий к коду не отличить никак. > Да, тут правда. > >> Вот тут уже сомнения. Если сжатые сроки, то потеря в среднем получаса > >> на каждое ревью... Это какие же должны быть разработчики, чтобы оно > >> окупалось? >
Re: Нюансы взаимодействия ZFS
On 02.04.2018 14:17, Dmitry Kulagin wrote: Отсюда вывод: всё-таки несмотря на "заверения экспертов" располагать ZFS pool лучше поверх LUKS, а не наоборот. LUKS почти не вносит оверхед. А кэширование записи диска всегда возможно включить вручную (как и подобрать размер блока, который у ZFS, к тому же, переменный). А после этого возникает закономерный вопрос: а зачем вам zfs? Вы только что избавились от одного из самых больших плюсов zfs и начали работать с device mapper, ну так продолжайте с ним работать, lvm и вперед, зачем плодить сущности? От какого же плюса я избавился? Как томами ZFS управлял, так и управляет. В чём тут проблема?
SAS hotswap и баг
Вытащил диск, вставил на место, но в /dev его не увидел. Зато увидел вот это в dmesg: [69497.081559] sd 0:0:5:0: [sdf] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [69916.705257] Buffer I/O error on dev dm-8, logical block 0, async page read [69930.896113] list_del corruption, 986c0632b010->next is LIST_POISON1 (dead0100) [69930.896226] [ cut here ] [69930.896227] kernel BUG at /build/linux-3RM5ap/linux-4.14.13/lib/list_debug.c:47! [69930.896329] invalid opcode: [#1] SMP PTI [69930.896416] Modules linked in: xt_nat veth ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat nf_conntrack br_netfilter bridge stp llc bonding xt_tcpudp cpufreq_conservative cpufreq_userspace cpufreq_powersave iptable_filter intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt iTCO_vendor_support kvm irqbypass ttm drm_kms_helper intel_cstate intel_uncore pcspkr intel_rapl_perf serio_raw drm evdev mei_me mei sg lpc_ich mfd_core shpchp ie31200_edac button nuvoton_cir ipmi_si battery ipmi_devintf rc_core ipmi_msghandler tpm_crb video acpi_pad nct6775 hwmon_vid jc42 coretemp ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) [69930.896925] spl(O) btrfs zstd_decompress zstd_compress xxhash algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod hid_generic usbhid hid crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd ahci glue_helper xhci_pci cryptd libahci mpt3sas igb xhci_hcd raid_class i2c_algo_bit libata scsi_transport_sas dca i2c_i801 ptp pps_core usbcore scsi_mod usb_common fan thermal [69930.897315] CPU: 7 PID: 15570 Comm: kworker/u16:2 Tainted: P O 4.14.0-0.bpo.3-amd64 #1 Debian 4.14.13-1~bpo9+1 [69930.897462] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./E3C224D4I-14S, BIOS P3.20 05/29/2015 [69930.897612] Workqueue: fw_event_mpt2sas0 _firmware_event_work [mpt3sas] [69930.897732] task: 986a138af040 task.stack: bbcfca9a8000 [69930.897846] RIP: 0010:__list_del_entry_valid+0x4e/0x90 [69930.897958] RSP: 0018:bbcfca9abb48 EFLAGS: 00010086 [69930.898070] RAX: 004e RBX: 0246 RCX: [69930.898185] RDX: RSI: 986c1fdd66f8 RDI: 986c1fdd66f8 [69930.898298] RBP: 986c0632b738 R08: R09: 0fdf [69930.898413] R10: 017d R11: 99b88e6d R12: 986c0636b180 [69930.898527] R13: 986c05f22000 R14: 986c0632b000 R15: 986c0d078010 [69930.898641] FS: () GS:986c1fdc() knlGS: [69930.898779] CS: 0010 DS: ES: CR0: 80050033 [69930.898892] CR2: 7fbe5e9f4ab4 CR3: 00019b40a005 CR4: 001606e0 [69930.899008] Call Trace: [69930.899121] scsi_device_dev_release_usercontext+0x55/0x260 [scsi_mod] [69930.899242] execute_in_process_context+0x5e/0x70 [69930.899358] device_release+0x2d/0x80 [69930.899467] kobject_put+0xa5/0x1a0 [69930.899580] scsi_remove_target+0x171/0x1b0 [scsi_mod] [69930.899699] sas_rphy_remove+0x55/0x60 [scsi_transport_sas] [69930.899814] sas_port_delete+0x2a/0x160 [scsi_transport_sas] [69930.899931] mpt3sas_transport_port_remove+0x1bc/0x220 [mpt3sas] [69930.900053] _scsih_remove_device+0x21d/0x330 [mpt3sas] [69930.900171] ? _scsih_sas_host_refresh+0x118/0x180 [mpt3sas] [69930.900290] _scsih_device_remove_by_handle.part.30+0x78/0xc0 [mpt3sas] [69930.900407] _firmware_event_work+0x15c7/0x1d80 [mpt3sas] [69930.900519] ? update_curr+0xf0/0x1a0 [69930.900627] ? pick_next_task_fair+0x156/0x570 [69930.900737] ? __switch_to+0xa8/0x450 [69930.900844] process_one_work+0x181/0x370 [69930.900953] worker_thread+0x4d/0x3c0 [69930.901061] kthread+0xfc/0x130 [69930.901168] ? process_one_work+0x370/0x370 [69930.901278] ? kthread_create_on_node+0x70/0x70 [69930.901388] ret_from_fork+0x1f/0x30 [69930.901494] Code: 74 2b 48 8b 12 48 39 d7 75 34 48 8b 50 08 48 39 d7 75 3c b8 01 00 00 00 c3 48 89 fe 48 89 c2 48 c7 c7 60 9e 44 99 e8 7d 21 d5 ff <0f> 0b 48 89 fe 48 c7 c7 98 9e 44 99 e8 6c 21 d5 ff 0f 0b 48 89 [69930.901702] RIP: __list_del_entry_valid+0x4e/0x90 RSP: bbcfca9abb48 [69930.901816] ---[ end trace b1b41653fc7fb543 ]--- Чтобы это могло быть?
