From owner-freebsd-hackers@freebsd.org Sun Jul 1 10:25:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A5EEFEFB2A for ; Sun, 1 Jul 2018 10:25:03 +0000 (UTC) (envelope-from anatoly@WHISPER.SU) Received: from mail.ferzi.org (walhalla.whisper.su [91.121.159.78]) by mx1.freebsd.org (Postfix) with ESMTP id D6BBC89F8F for ; Sun, 1 Jul 2018 10:25:00 +0000 (UTC) (envelope-from anatoly@WHISPER.SU) Received: from internal.domain; Sun, 01 Jul 2018 12:24:52 +0300 Received: from internal.domain; Sun, 01 Jul 2018 12:24:52 +0300 To: freebsd-hackers@freebsd.org From: anatoly@WHISPER.SU Subject: 11.2-RELEASE/efirt compile error Message-ID: Date: Sun, 1 Jul 2018 12:24:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 10:25:03 -0000 hi everyone! Trying to rebuild kernel from 11.1->11.2 RELEASE, till binary update there was no problem at all with migrations but now im getting following error building efirt module, tried to google a bit - nothing, maybe someone already fixed it? ===> efirt (all) cc -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include /usr/src/sys/amd64/compile/KERNEL/opt_global.h -I. -I/usr/src/sys -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -I/usr/src/sys/amd64/compile/KERNEL   -MD  -MF.depend.efirt.o -MTefirt.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member  -mno-aes -mno-avx -std=iso9899:1999 -c /usr/src/sys/sys/amd64/amd64/efirt.c -o efirt.o /usr/src/sys/sys/amd64/amd64/efirt.c:124:1: error: control reaches end of non-void function       [-Werror,-Wreturn-type] } ^ /usr/src/sys/sys/amd64/amd64/efirt.c:186:1: error: static declaration of       'efi_create_1t1_map' follows non-static declaration efi_create_1t1_map(struct efi_md *map, int ndesc, int descsz) ^ /usr/src/sys/sys/efi.h:175:6: note: previous declaration is here bool efi_create_1t1_map(struct efi_md *, int, int);      ^ /usr/src/sys/sys/amd64/amd64/efirt.c:441:1: error: no previous prototype for function       'efi_get_time_locked' [-Werror,-Wmissing-prototypes] efi_get_time_locked(struct efi_tm *tm) ^ /usr/src/sys/sys/amd64/amd64/efirt.c:463:12: error: use of undeclared identifier       'resettodr_lock'         mtx_lock(&resettodr_lock);                   ^ /usr/src/sys/sys/amd64/amd64/efirt.c:465:14: error: use of undeclared identifier       'resettodr_lock'         mtx_unlock(&resettodr_lock);                     ^ /usr/src/sys/sys/amd64/amd64/efirt.c:483:1: error: no previous prototype for function       'efi_set_time_locked' [-Werror,-Wmissing-prototypes] efi_set_time_locked(struct efi_tm *tm) ^ /usr/src/sys/sys/amd64/amd64/efirt.c:505:12: error: use of undeclared identifier       'resettodr_lock'         mtx_lock(&resettodr_lock);                   ^ /usr/src/sys/sys/amd64/amd64/efirt.c:507:14: error: use of undeclared identifier       'resettodr_lock'         mtx_unlock(&resettodr_lock);                     ^ 8 errors generated. *** Error code 1 Stop. make[2]: stopped in /usr/src/sys/modules/efirt *** Error code 1 Stop. make[1]: stopped in /usr/src/sys/modules *** Error code 1 Stop. make: stopped in /usr/src/sys/amd64/compile/KERNEL part of kernel config: device          vga                     # VGA video card driver options         VESA                    # Add support for VESA BIOS Extensions (VBE) device          splash                  # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device          sc options         SC_PIXEL_MODE           # add support for the raster text mode # vt is the new video console driver device          vt device          vt_vga #device          vt_efifb -- Anatoly From owner-freebsd-hackers@freebsd.org Sun Jul 1 11:15:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24966FF3B2F for ; Sun, 1 Jul 2018 11:15:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98FDB8C218 for ; Sun, 1 Jul 2018 11:15:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w61BFISm037840 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Jul 2018 14:15:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w61BFISm037840 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w61BFIQp037839; Sun, 1 Jul 2018 14:15:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 1 Jul 2018 14:15:18 +0300 From: Konstantin Belousov To: anatoly@WHISPER.SU Cc: freebsd-hackers@freebsd.org Subject: Re: 11.2-RELEASE/efirt compile error Message-ID: <20180701111518.GY2430@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 11:15:34 -0000 On Sun, Jul 01, 2018 at 12:24:51PM +0300, anatoly@WHISPER.SU wrote: > hi everyone! > > Trying to rebuild kernel from 11.1->11.2 RELEASE, till binary update > there was no problem at all with migrations but now im getting following > error building efirt module, tried to google a bit - nothing, > maybe someone already fixed it? > > ===> efirt (all) > cc -O2 -pipeš -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdincšš -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/src/sys/amd64/compile/KERNEL/opt_global.h -I. -I/usr/src/sys > -fno-commonš -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > -I/usr/src/sys/amd64/compile/KERNELšš -MDš -MF.depend.efirt.o -MTefirt.o > -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-floatš > -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector > -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ > -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -Wno-error-unused-function > -Wno-error-pointer-sign -Wno-error-shift-negative-value > -Wno-error-address-of-packed-memberš -mno-aes -mno-avx -std=iso9899:1999 > -c /usr/src/sys/sys/amd64/amd64/efirt.c -o efirt.o > /usr/src/sys/sys/amd64/amd64/efirt.c:124:1: error: control reaches end > of non-void function > ššššš [-Werror,-Wreturn-type] > } > ^ > /usr/src/sys/sys/amd64/amd64/efirt.c:186:1: error: static declaration of > ššššš 'efi_create_1t1_map' follows non-static declaration > efi_create_1t1_map(struct efi_md *map, int ndesc, int descsz) > ^ There is no sys/amd64/amd64/efirt.c in 11.2 sources. > /usr/src/sys/sys/efi.h:175:6: note: previous declaration is here > bool efi_create_1t1_map(struct efi_md *, int, int); > šššš ^ > /usr/src/sys/sys/amd64/amd64/efirt.c:441:1: error: no previous prototype > for function > ššššš 'efi_get_time_locked' [-Werror,-Wmissing-prototypes] > efi_get_time_locked(struct efi_tm *tm) > ^ > /usr/src/sys/sys/amd64/amd64/efirt.c:463:12: error: use of undeclared > identifier > ššššš 'resettodr_lock' > ššššššš mtx_lock(&resettodr_lock); > ššššššššššššššššš ^ > /usr/src/sys/sys/amd64/amd64/efirt.c:465:14: error: use of undeclared > identifier > ššššš 'resettodr_lock' > ššššššš mtx_unlock(&resettodr_lock); > ššššššššššššššššššš ^ > /usr/src/sys/sys/amd64/amd64/efirt.c:483:1: error: no previous prototype > for function > ššššš 'efi_set_time_locked' [-Werror,-Wmissing-prototypes] > efi_set_time_locked(struct efi_tm *tm) > ^ > /usr/src/sys/sys/amd64/amd64/efirt.c:505:12: error: use of undeclared > identifier > ššššš 'resettodr_lock' > ššššššš mtx_lock(&resettodr_lock); > ššššššššššššššššš ^ > /usr/src/sys/sys/amd64/amd64/efirt.c:507:14: error: use of undeclared > identifier > ššššš 'resettodr_lock' > ššššššš mtx_unlock(&resettodr_lock); > ššššššššššššššššššš ^ > 8 errors generated. > *** Error code 1 > > Stop. > make[2]: stopped in /usr/src/sys/modules/efirt > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src/sys/modules > *** Error code 1 > > Stop. > make: stopped in /usr/src/sys/amd64/compile/KERNEL > > part of kernel config: > deviceššššššššš vgašššššššššššššššššššš # VGA video card driver > optionsšššššššš VESAššššššššššššššššššš # Add support for VESA BIOS > Extensions (VBE) > > deviceššššššššš splashššššššššššššššššš # Splash screen and screen saver > support > > # syscons is the default console driver, resembling an SCO console > deviceššššššššš sc > optionsšššššššš SC_PIXEL_MODEšššššššššš # add support for the raster > text mode > > # vt is the new video console driver > deviceššššššššš vt > deviceššššššššš vt_vga > #deviceššššššššš vt_efifb > > -- > Anatoly > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sun Jul 1 12:16:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C9DBFF5820 for ; Sun, 1 Jul 2018 12:16:59 +0000 (UTC) (envelope-from anatoly@WHISPER.SU) Received: from mail.ferzi.org (walhalla.whisper.su [91.121.159.78]) by mx1.freebsd.org (Postfix) with ESMTP id 72D328DE94 for ; Sun, 1 Jul 2018 12:16:58 +0000 (UTC) (envelope-from anatoly@WHISPER.SU) Received: from internal.domain; Sun, 01 Jul 2018 15:16:57 +0300 Received: from internal.domain; Sun, 01 Jul 2018 15:16:56 +0300 Subject: Re: 11.2-RELEASE/efirt compile error To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org References: <20180701111518.GY2430@kib.kiev.ua> From: anatoly@WHISPER.SU Message-ID: <79151248-d615-0a7e-d08f-96679551c083@WHISPER.SU> Date: Sun, 1 Jul 2018 15:16:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180701111518.GY2430@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 12:16:59 -0000 Konstantin, thanks for response, but it exists: MD5 (./sys/amd64/amd64/efirt.c) = ddc9b6b4e79f12ee8588dbea3d2a010d 01.07.2018 14:15, Konstantin Belousov пишет: > On Sun, Jul 01, 2018 at 12:24:51PM +0300, anatoly@WHISPER.SU wrote: >> hi everyone! >> >> Trying to rebuild kernel from 11.1->11.2 RELEASE, till binary update >> there was no problem at all with migrations but now im getting following >> error building efirt module, tried to google a bit - nothing, >> maybe someone already fixed it? >> >> ===> efirt (all) >> cc -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE >> -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include >> /usr/src/sys/amd64/compile/KERNEL/opt_global.h -I. -I/usr/src/sys >> -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer >> -I/usr/src/sys/amd64/compile/KERNEL   -MD  -MF.depend.efirt.o -MTefirt.o >> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float >> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector >> -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ >> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas >> -Wno-error-tautological-compare -Wno-error-empty-body >> -Wno-error-parentheses-equality -Wno-error-unused-function >> -Wno-error-pointer-sign -Wno-error-shift-negative-value >> -Wno-error-address-of-packed-member  -mno-aes -mno-avx -std=iso9899:1999 >> -c /usr/src/sys/sys/amd64/amd64/efirt.c -o efirt.o >> /usr/src/sys/sys/amd64/amd64/efirt.c:124:1: error: control reaches end >> of non-void function >>       [-Werror,-Wreturn-type] >> } >> ^ >> /usr/src/sys/sys/amd64/amd64/efirt.c:186:1: error: static declaration of >>       'efi_create_1t1_map' follows non-static declaration >> efi_create_1t1_map(struct efi_md *map, int ndesc, int descsz) >> ^ > There is no sys/amd64/amd64/efirt.c in 11.2 sources. > >> /usr/src/sys/sys/efi.h:175:6: note: previous declaration is here >> bool efi_create_1t1_map(struct efi_md *, int, int); >>      ^ >> /usr/src/sys/sys/amd64/amd64/efirt.c:441:1: error: no previous prototype >> for function >>       'efi_get_time_locked' [-Werror,-Wmissing-prototypes] >> efi_get_time_locked(struct efi_tm *tm) >> ^ >> /usr/src/sys/sys/amd64/amd64/efirt.c:463:12: error: use of undeclared >> identifier >>       'resettodr_lock' >>         mtx_lock(&resettodr_lock); >>                   ^ >> /usr/src/sys/sys/amd64/amd64/efirt.c:465:14: error: use of undeclared >> identifier >>       'resettodr_lock' >>         mtx_unlock(&resettodr_lock); >>                     ^ >> /usr/src/sys/sys/amd64/amd64/efirt.c:483:1: error: no previous prototype >> for function >>       'efi_set_time_locked' [-Werror,-Wmissing-prototypes] >> efi_set_time_locked(struct efi_tm *tm) >> ^ >> /usr/src/sys/sys/amd64/amd64/efirt.c:505:12: error: use of undeclared >> identifier >>       'resettodr_lock' >>         mtx_lock(&resettodr_lock); >>                   ^ >> /usr/src/sys/sys/amd64/amd64/efirt.c:507:14: error: use of undeclared >> identifier >>       'resettodr_lock' >>         mtx_unlock(&resettodr_lock); >>                     ^ >> 8 errors generated. >> *** Error code 1 >> >> Stop. >> make[2]: stopped in /usr/src/sys/modules/efirt >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/src/sys/modules >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/src/sys/amd64/compile/KERNEL >> >> part of kernel config: >> device          vga                     # VGA video card driver >> options         VESA                    # Add support for VESA BIOS >> Extensions (VBE) >> >> device          splash                  # Splash screen and screen saver >> support >> >> # syscons is the default console driver, resembling an SCO console >> device          sc >> options         SC_PIXEL_MODE           # add support for the raster >> text mode >> >> # vt is the new video console driver >> device          vt >> device          vt_vga >> #device          vt_efifb >> >> -- >> Anatoly >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sun Jul 1 12:26:14 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EF8A8FF5B05 for ; Sun, 1 Jul 2018 12:26:13 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81A098E29C for ; Sun, 1 Jul 2018 12:26:13 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yb0-x230.google.com with SMTP id e9-v6so4170862ybq.1 for ; Sun, 01 Jul 2018 05:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CNNLc2Yvd7LlItW87iihdwJj7/SK5iwFLQhvTuER08o=; b=UIRXg7v3kxpUPXiWEptrD64vYX2B79ibU0T/PZa1ads3ywKeq2OSHWZ8tTeZPiLa7i 5PYMFGQk4Sfjhug9gsGEdiplIxUwU5ahrcRGqNJxKynhxE5zNmUWfYQtdfvoH1NPcBii Zv9ltFDwRdKYQ7pHJgQOkYY4USu8EDb0c9Tls9PnC6ts369tF07xqH+w83MpXe/1F4XZ Y4rIIr9Hb3hcfTe5owAPwaOMgzXWJH0GCEhE+xhHGpJQenM0ejDM3XzhZ7IEhn6MLay4 usg3VvGV9x69snc8WIP7HSPA/yMQsyVXKjZNo+ECwJkH0AUcFiMdPe367vFMAgXhqzqB VufA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CNNLc2Yvd7LlItW87iihdwJj7/SK5iwFLQhvTuER08o=; b=qyPoR1Wbn1E6skYRGLRHGBINRXgd0Ply3incIABcDtXCFqu4JZfEmqLu59MwDkPuBd /bTWGIl3k1qq7a1mJUtrEWySjYySXiPNyO1R86kqO6TkF+8izzpqyZklmqzwTBie6lv0 e8ZUbH2QtOI2N9yKnMb4erY9Ykn2Jkp4xdKqt5GNnc/mHzXuh889HqlFFNBI031g3gxm nQZo77PYy5o946EFJ1z9LnS3yW90gYZCf2YIeilMNeTejEymPh///hf34DItspW309Yz 6LNcqco/Hc2Ki5ZCA836poxCMiDSa4JEeBz9SSY3kJ2sUYH/N9VXd1KLxCeNN2+zs54K hQPA== X-Gm-Message-State: APt69E120jSOkfvO8HhK/SXHskeAv3kbFoZnWZPcI7pW4wTQ6vHA9zjk 6611Cnp5ymlqnlA05f0Opi4hSpWmWi2iQcsXoFtPyA== X-Google-Smtp-Source: AAOMgpepRDrVWK/wPq3cdSelZEsjsGwGCJbpNiFdMNS3fVs+HuAj8ik56aAGLqgA9XRHNZE1Ei5Oy/oaggEBjz+GP5c= X-Received: by 2002:a25:13c2:: with SMTP id 185-v6mr215227ybt.331.1530447972623; Sun, 01 Jul 2018 05:26:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:b90:0:0:0:0:0 with HTTP; Sun, 1 Jul 2018 05:26:12 -0700 (PDT) In-Reply-To: <79151248-d615-0a7e-d08f-96679551c083@WHISPER.SU> References: <20180701111518.GY2430@kib.kiev.ua> <79151248-d615-0a7e-d08f-96679551c083@WHISPER.SU> From: Oliver Pinter Date: Sun, 1 Jul 2018 14:26:12 +0200 Message-ID: Subject: Re: 11.2-RELEASE/efirt compile error To: "anatoly@whisper.su" Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 12:26:14 -0000 On Sunday, July 1, 2018, wrote: > Konstantin, thanks for response, but it exists: > > MD5 (./sys/amd64/amd64/efirt.c) =3D ddc9b6b4e79f12ee8588dbea3d2a010d Nope: https://github.com/freebsd/freebsd/tree/releng/11.2/sys/amd64/amd64 > > > 01.07.2018 14:15, Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> On Sun, Jul 01, 2018 at 12:24:51PM +0300, anatoly@WHISPER.SU wrote: >> >>> hi everyone! >>> >>> Trying to rebuild kernel from 11.1->11.2 RELEASE, till binary update >>> there was no problem at all with migrations but now im getting followin= g >>> error building efirt module, tried to google a bit - nothing, >>> maybe someone already fixed it? >>> >>> =3D=3D=3D> efirt (all) >>> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE >>> -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include >>> /usr/src/sys/amd64/compile/KERNEL/opt_global.h -I. -I/usr/src/sys >>> -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer >>> -I/usr/src/sys/amd64/compile/KERNEL -MD -MF.depend.efirt.o -MTefirt.= o >>> -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float >>> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protecto= r >>> -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >>> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >>> -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ >>> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas >>> -Wno-error-tautological-compare -Wno-error-empty-body >>> -Wno-error-parentheses-equality -Wno-error-unused-function >>> -Wno-error-pointer-sign -Wno-error-shift-negative-value >>> -Wno-error-address-of-packed-member -mno-aes -mno-avx -std=3Diso9899:1= 999 >>> -c /usr/src/sys/sys/amd64/amd64/efirt.c -o efirt.o >>> /usr/src/sys/sys/amd64/amd64/efirt.c:124:1: error: control reaches end >>> of non-void function >>> [-Werror,-Wreturn-type] >>> } >>> ^ >>> /usr/src/sys/sys/amd64/amd64/efirt.c:186:1: error: static declaration o= f >>> 'efi_create_1t1_map' follows non-static declaration >>> efi_create_1t1_map(struct efi_md *map, int ndesc, int descsz) >>> ^ >>> >> There is no sys/amd64/amd64/efirt.c in 11.2 sources. >> >> /usr/src/sys/sys/efi.h:175:6: note: previous declaration is here >>> bool efi_create_1t1_map(struct efi_md *, int, int); >>> ^ >>> /usr/src/sys/sys/amd64/amd64/efirt.c:441:1: error: no previous prototyp= e >>> for function >>> 'efi_get_time_locked' [-Werror,-Wmissing-prototypes] >>> efi_get_time_locked(struct efi_tm *tm) >>> ^ >>> /usr/src/sys/sys/amd64/amd64/efirt.c:463:12: error: use of undeclared >>> identifier >>> 'resettodr_lock' >>> mtx_lock(&resettodr_lock); >>> ^ >>> /usr/src/sys/sys/amd64/amd64/efirt.c:465:14: error: use of undeclared >>> identifier >>> 'resettodr_lock' >>> mtx_unlock(&resettodr_lock); >>> ^ >>> /usr/src/sys/sys/amd64/amd64/efirt.c:483:1: error: no previous prototyp= e >>> for function >>> 'efi_set_time_locked' [-Werror,-Wmissing-prototypes] >>> efi_set_time_locked(struct efi_tm *tm) >>> ^ >>> /usr/src/sys/sys/amd64/amd64/efirt.c:505:12: error: use of undeclared >>> identifier >>> 'resettodr_lock' >>> mtx_lock(&resettodr_lock); >>> ^ >>> /usr/src/sys/sys/amd64/amd64/efirt.c:507:14: error: use of undeclared >>> identifier >>> 'resettodr_lock' >>> mtx_unlock(&resettodr_lock); >>> ^ >>> 8 errors generated. >>> *** Error code 1 >>> >>> Stop. >>> make[2]: stopped in /usr/src/sys/modules/efirt >>> *** Error code 1 >>> >>> Stop. >>> make[1]: stopped in /usr/src/sys/modules >>> *** Error code 1 >>> >>> Stop. >>> make: stopped in /usr/src/sys/amd64/compile/KERNEL >>> >>> part of kernel config: >>> device vga # VGA video card driver >>> options VESA # Add support for VESA BIOS >>> Extensions (VBE) >>> >>> device splash # Splash screen and screen save= r >>> support >>> >>> # syscons is the default console driver, resembling an SCO console >>> device sc >>> options SC_PIXEL_MODE # add support for the raster >>> text mode >>> >>> # vt is the new video console driver >>> device vt >>> device vt_vga >>> #device vt_efifb >>> >>> -- >>> Anatoly >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@ >>> freebsd.org" >>> >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Sun Jul 1 12:26:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26CC4FF5B19 for ; Sun, 1 Jul 2018 12:26:28 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (unknown [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 997958E2A7 for ; Sun, 1 Jul 2018 12:26:27 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w61CQH17060053 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 1 Jul 2018 14:26:18 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: anatoly@WHISPER.SU Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w61CQ3GG037649 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 1 Jul 2018 19:26:03 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: 11.2-RELEASE/efirt compile error To: anatoly@WHISPER.SU, Konstantin Belousov References: <20180701111518.GY2430@kib.kiev.ua> <79151248-d615-0a7e-d08f-96679551c083@WHISPER.SU> Cc: freebsd-hackers@freebsd.org From: Eugene Grosbein Message-ID: <5B38C85B.50706@grosbein.net> Date: Sun, 1 Jul 2018 19:26:03 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <79151248-d615-0a7e-d08f-96679551c083@WHISPER.SU> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, SPF_PASS,T_DATE_IN_FUTURE_96_Q autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 T_DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 12:26:28 -0000 01.07.2018 19:16, anatoly@WHISPER.SU wrote: > Konstantin, thanks for response, but it exists: > > MD5 (./sys/amd64/amd64/efirt.c) = ddc9b6b4e79f12ee8588dbea3d2a010d Your local tree got broken somehow. There is no such file in the Repo but sys/dev/efidev/efirt.c. Delete your /usr/src and fetch it again. From owner-freebsd-hackers@freebsd.org Sun Jul 1 12:28:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40746FF5BDC for ; Sun, 1 Jul 2018 12:28:09 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCDB18E42D for ; Sun, 1 Jul 2018 12:28:08 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yw0-x22c.google.com with SMTP id y203-v6so4047429ywd.9 for ; Sun, 01 Jul 2018 05:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lOJg01S3LKck9ECjXyucrG3nUyHLbXHVeRDbHQVhi/w=; b=F4Be0l+deEqRet99M8INUNb/GPAZwz9ety+jF+ThsKDjJlVfj1QXKDXAj0E7uYW3YN LSyCkeW8Hro/PB81Y86wHKEghunKC0vEzloN0/Mtcaj2QNiTrbZrMdIonlNY3Zt5vZVF R2GSe95I3qfROnW2/xT0mv18AkNLe6IVSlwDQOtZKDkgwh0W3jJmUw2lbnaLcPhePzZi zJtAqu8cRS/R+/eRRFttJ199BL/r/zWqxIr4FsXuhBd4VA0XCKu2m5BuI8bXA5UNj4rb iyRcuQOGu9x8lATSKZJGjxNzXAWUQycKY1u4NscHx6QFmM1LYbawCgWsRrCW7Wg1pULD qJ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lOJg01S3LKck9ECjXyucrG3nUyHLbXHVeRDbHQVhi/w=; b=V3gX/W2XnZ6CLI1oGtH1Pi8gdF6n5ZTmkxLEV9Pia9Cf0wNnRerot99taVvq8yZbwE fDHLqpR9BACrJ3dXtRjX0JYtIJ9vNlZUUHOtK7vtDEp59R2udESxv6RI639SRYq3EfeE ZlGpiUKWxSIUxPiIk6lsnsywd2WxQgFzQZGdxUVfNt6z737PWJAwjIpRr3vJR4DSgL7r r3Yq4ivgW+bsDoGRopvaGmgHE2RqLdH+3ytlO7eQn9dLuM1plWVekIc+RYYaBdq15x8M D5cRiLTKFgaABBch/TCflYfZzp+1BFwrJra5M1Vxy4ODeJi2ZsrDkRhSYS61yUA7Vk+R M+rw== X-Gm-Message-State: APt69E1kc8kWXIvlJ4denM2IyJSI0rzeFP9NwG72Al34O6Ij2MyYA+Sn MYQCuSP73KUuevdRNr2o303WjCE7DOwBTvqHTCiFwQ== X-Google-Smtp-Source: AAOMgpeO/oADDzs6K84E3UI8qvxoycMVnwkfdkol+7axaF/IK87encG5Tmn0eqAjcGO09K9ZlxIq5s3i0uZWs1OtOy8= X-Received: by 2002:a81:69d4:: with SMTP id e203-v6mr1505070ywc.265.1530448088298; Sun, 01 Jul 2018 05:28:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:b90:0:0:0:0:0 with HTTP; Sun, 1 Jul 2018 05:28:07 -0700 (PDT) In-Reply-To: References: <20180701111518.GY2430@kib.kiev.ua> <79151248-d615-0a7e-d08f-96679551c083@WHISPER.SU> From: Oliver Pinter Date: Sun, 1 Jul 2018 14:28:07 +0200 Message-ID: Subject: Re: 11.2-RELEASE/efirt compile error To: "anatoly@whisper.su" Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 12:28:09 -0000 On Sunday, July 1, 2018, Oliver Pinter wrote: > > > On Sunday, July 1, 2018, wrote: > >> Konstantin, thanks for response, but it exists: >> >> MD5 (./sys/amd64/amd64/efirt.c) =3D ddc9b6b4e79f12ee8588dbea3d2a010d > > > Nope: https://github.com/freebsd/freebsd/tree/releng/11.2/sys/amd64/amd64 > Neither here: https://github.com/freebsd/freebsd/tree/release/11.2.0/sys/amd64/amd64 > >> >> 01.07.2018 14:15, Konstantin Belousov =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >>> On Sun, Jul 01, 2018 at 12:24:51PM +0300, anatoly@WHISPER.SU wrote: >>> >>>> hi everyone! >>>> >>>> Trying to rebuild kernel from 11.1->11.2 RELEASE, till binary update >>>> there was no problem at all with migrations but now im getting followi= ng >>>> error building efirt module, tried to google a bit - nothing, >>>> maybe someone already fixed it? >>>> >>>> =3D=3D=3D> efirt (all) >>>> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE >>>> -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include >>>> /usr/src/sys/amd64/compile/KERNEL/opt_global.h -I. -I/usr/src/sys >>>> -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer >>>> -I/usr/src/sys/amd64/compile/KERNEL -MD -MF.depend.efirt.o >>>> -MTefirt.o >>>> -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-float >>>> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv >>>> -fstack-protector >>>> -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >>>> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef >>>> -Wno-pointer-sign -D__printf__=3D__freebsd_kprintf__ >>>> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas >>>> -Wno-error-tautological-compare -Wno-error-empty-body >>>> -Wno-error-parentheses-equality -Wno-error-unused-function >>>> -Wno-error-pointer-sign -Wno-error-shift-negative-value >>>> -Wno-error-address-of-packed-member -mno-aes -mno-avx >>>> -std=3Diso9899:1999 >>>> -c /usr/src/sys/sys/amd64/amd64/efirt.c -o efirt.o >>>> /usr/src/sys/sys/amd64/amd64/efirt.c:124:1: error: control reaches end >>>> of non-void function >>>> [-Werror,-Wreturn-type] >>>> } >>>> ^ >>>> /usr/src/sys/sys/amd64/amd64/efirt.c:186:1: error: static declaration >>>> of >>>> 'efi_create_1t1_map' follows non-static declaration >>>> efi_create_1t1_map(struct efi_md *map, int ndesc, int descsz) >>>> ^ >>>> >>> There is no sys/amd64/amd64/efirt.c in 11.2 sources. >>> >>> /usr/src/sys/sys/efi.h:175:6: note: previous declaration is here >>>> bool efi_create_1t1_map(struct efi_md *, int, int); >>>> ^ >>>> /usr/src/sys/sys/amd64/amd64/efirt.c:441:1: error: no previous >>>> prototype >>>> for function >>>> 'efi_get_time_locked' [-Werror,-Wmissing-prototypes] >>>> efi_get_time_locked(struct efi_tm *tm) >>>> ^ >>>> /usr/src/sys/sys/amd64/amd64/efirt.c:463:12: error: use of undeclared >>>> identifier >>>> 'resettodr_lock' >>>> mtx_lock(&resettodr_lock); >>>> ^ >>>> /usr/src/sys/sys/amd64/amd64/efirt.c:465:14: error: use of undeclared >>>> identifier >>>> 'resettodr_lock' >>>> mtx_unlock(&resettodr_lock); >>>> ^ >>>> /usr/src/sys/sys/amd64/amd64/efirt.c:483:1: error: no previous >>>> prototype >>>> for function >>>> 'efi_set_time_locked' [-Werror,-Wmissing-prototypes] >>>> efi_set_time_locked(struct efi_tm *tm) >>>> ^ >>>> /usr/src/sys/sys/amd64/amd64/efirt.c:505:12: error: use of undeclared >>>> identifier >>>> 'resettodr_lock' >>>> mtx_lock(&resettodr_lock); >>>> ^ >>>> /usr/src/sys/sys/amd64/amd64/efirt.c:507:14: error: use of undeclared >>>> identifier >>>> 'resettodr_lock' >>>> mtx_unlock(&resettodr_lock); >>>> ^ >>>> 8 errors generated. >>>> *** Error code 1 >>>> >>>> Stop. >>>> make[2]: stopped in /usr/src/sys/modules/efirt >>>> *** Error code 1 >>>> >>>> Stop. >>>> make[1]: stopped in /usr/src/sys/modules >>>> *** Error code 1 >>>> >>>> Stop. >>>> make: stopped in /usr/src/sys/amd64/compile/KERNEL >>>> >>>> part of kernel config: >>>> device vga # VGA video card driver >>>> options VESA # Add support for VESA BIOS >>>> Extensions (VBE) >>>> >>>> device splash # Splash screen and screen sav= er >>>> support >>>> >>>> # syscons is the default console driver, resembling an SCO console >>>> device sc >>>> options SC_PIXEL_MODE # add support for the raster >>>> text mode >>>> >>>> # vt is the new video console driver >>>> device vt >>>> device vt_vga >>>> #device vt_efifb >>>> >>>> -- >>>> Anatoly >>>> _______________________________________________ >>>> freebsd-hackers@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@f >>>> reebsd.org" >>>> >>> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g >> " >> > From owner-freebsd-hackers@freebsd.org Sun Jul 1 13:46:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45D22FF78FC for ; Sun, 1 Jul 2018 13:46:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-31.consmr.mail.ne1.yahoo.com (sonic301-31.consmr.mail.ne1.yahoo.com [66.163.184.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CEC3B706CA for ; Sun, 1 Jul 2018 13:46:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: QnQVvS8VM1kByF3K8AvkuUzYGHK15sbJdAiNOmCaleMLigtkoWxB.CqJfk4v8Kl tm2Jr2Gz_E599U9reCmeKxxvh9ZNkPW5gpnA9_HVVCOd9.kKtLZn2wgGdrI4t0AjveJaNxkKNeuP jHJ9PSttUKS0DAE2ItttxM6OSR_B4wE8Q9BXDeQA6zeAWcBzxghmYASI8wm8QGWrSmmdLUbXvXeh r_iCTpGL8za_jhk_NtRSdCyOgQVOgKT.OsTjQeHTFEJuN0twzI2djs7vdplkb1jj2mRbyUQAhBSV 7SFM0akPxCot2Ft_buOtc7tY5JDc9f.FRvoMlfns9lVjFRVqHbRTa7cSu8_p9cS93SCULWrmNzRM B3WjU_WoT7Lz5ycRaSFDaYApxXPkFYwzx9siFi_D9UA4.UGDRVXT5TDxkGttf7aKBev8fntCC5sl abPnzBzJ_F1WuHNHDkNJsgdEoXILVX4YLLCOydXlklhvJ4bliBl3gJyjrZlKTXxsMalT8w7q_jjQ ZAmdr6SLlICUhGPD2nUwh6wsszYjdVBMdarTMAdaMwkMHx58SI2.VVbP1K6ZhyBDudyqZ_p77XCP qqu9wxEErAdDTeVlNmcFqFLQ2fs_Wz1R.P.Fjl6NaUGMH1ds.XxwmaRrtK_DKqIRFOBCRGGQ2flT H2auuOBPCng6ITlwtkLmb5K_pKuod27_JFzk.h8QQR6xTNj.Iagn3XrhmW0uI3SITofs4pSQ3RQS Kg3vbN8Q3wJ_mQmWaE1Dm6LDQwE2EnJ0ZDndLbULuQbhpE33AWj5lx98YEaktIBtpXw5.tyuodmF 7wqSOiW7fnzxIEbfaLRUyBYSokGXy4XkE9.IecEXIbshBeluwHazfZqLS8.6oZwRZ46OVmyoEJUy fPMN2y66MtEBmcc0BM2CuTKZswmvALn8D7ZMdEs8CuoLMJDyxes4ngCNbAqmwmem6LqkoZsLLux. 9j0AhyTVdZtd5Kx_MRo_CA.6ThINZHNI_vl6TzXnX0d4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Sun, 1 Jul 2018 13:46:01 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp404.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 17cc6c778d209f1e16404427b2f38e02; Sun, 01 Jul 2018 13:45:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: 11.2-RELEASE/efirt compile error From: Mark Millard In-Reply-To: Date: Sun, 1 Jul 2018 06:45:54 -0700 Cc: Oliver Pinter , Konstantin Belousov , "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180701111518.GY2430@kib.kiev.ua> <79151248-d615-0a7e-d08f-96679551c083@WHISPER.SU> To: "anatoly@whisper.su" X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 13:46:08 -0000 > On 2018-Jul-1, at 5:28 AM, Oliver Pinter wrote: >=20 > On Sunday, July 1, 2018, Oliver Pinter > wrote: >=20 >>=20 >>=20 >> On Sunday, July 1, 2018, wrote: >>=20 >>> Konstantin, thanks for response, but it exists: >>>=20 >>> MD5 (./sys/amd64/amd64/efirt.c) =3D ddc9b6b4e79f12ee8588dbea3d2a010d >>=20 >>=20 >> Nope: = https://github.com/freebsd/freebsd/tree/releng/11.2/sys/amd64/amd64 >>=20 >=20 > Neither here: > https://github.com/freebsd/freebsd/tree/release/11.2.0/sys/amd64/amd64 >=20 Or to reference svn: https://svnweb.freebsd.org/base/release/11.2.0/sys/amd64/amd64/ shows a efirt_machdep.c but no efirt.c file. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Sun Jul 1 15:36:07 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F37AFF9AD4 for ; Sun, 1 Jul 2018 15:36:07 +0000 (UTC) (envelope-from anatoly@WHISPER.SU) Received: from mail.ferzi.org (walhalla.whisper.su [91.121.159.78]) by mx1.freebsd.org (Postfix) with ESMTP id 457E37384E for ; Sun, 1 Jul 2018 15:36:05 +0000 (UTC) (envelope-from anatoly@WHISPER.SU) Received: from internal.domain; Sun, 01 Jul 2018 18:36:04 +0300 Received: from internal.domain; Sun, 01 Jul 2018 18:36:03 +0300 Subject: Re: 11.2-RELEASE/efirt compile error To: Mark Millard Cc: Oliver Pinter , Konstantin Belousov , "freebsd-hackers@freebsd.org" References: <20180701111518.GY2430@kib.kiev.ua> <79151248-d615-0a7e-d08f-96679551c083@WHISPER.SU> From: anatoly@WHISPER.SU Message-ID: <48970d2e-85f6-6b49-09a9-be24679dc5fc@WHISPER.SU> Date: Sun, 1 Jul 2018 18:36:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2018 15:36:07 -0000 yup, just changed svn from svn.freebsd.org to svn0.eu.freebsd.org, everything is ok. thanks! 01.07.2018 16:45, Mark Millard пишет: > >> On 2018-Jul-1, at 5:28 AM, Oliver Pinter wrote: >> >> On Sunday, July 1, 2018, Oliver Pinter >> wrote: >> >>> >>> On Sunday, July 1, 2018, wrote: >>> >>>> Konstantin, thanks for response, but it exists: >>>> >>>> MD5 (./sys/amd64/amd64/efirt.c) = ddc9b6b4e79f12ee8588dbea3d2a010d >>> >>> Nope: https://github.com/freebsd/freebsd/tree/releng/11.2/sys/amd64/amd64 >>> >> Neither here: >> https://github.com/freebsd/freebsd/tree/release/11.2.0/sys/amd64/amd64 >> > Or to reference svn: > > https://svnweb.freebsd.org/base/release/11.2.0/sys/amd64/amd64/ > > shows a efirt_machdep.c but no efirt.c file. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > From owner-freebsd-hackers@freebsd.org Mon Jul 2 12:53:32 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F17B41026303 for ; Mon, 2 Jul 2018 12:53:31 +0000 (UTC) (envelope-from munro@penski.net) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6750986563 for ; Mon, 2 Jul 2018 12:53:31 +0000 (UTC) (envelope-from munro@penski.net) Received: by mail-ed1-x52f.google.com with SMTP id t3-v6so11664844eds.3 for ; Mon, 02 Jul 2018 05:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=penski-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=6hqYwZIMe6fzuXhF+yLf4P5PpHUNaSToHpM8pe3m6rk=; b=W7ndwEK/bb4b+D6ZBw1L+lYdA52h00Utgkg1Jpuaj9eM78SWyIM/PgotISNwvM/VGr 3GJpAn/MfZZpND41FNzQ5DXSOJE38ofAASRj3CsTTHis7Yr3SfBryBFKGIsHpAV36Aqn tMmevyBUukysJG2HEBzwRdAj4l8Dg4vE/7O+BodPGWqaK0Nbey9b2Xkav9tkeKaYe3jW jlSt088VekPnQCOYXGivW92BmmA7uN95owJJJ/xoHH8TtG8fWTou8ptXnzDlhe03/U+x hNaeNMCUZJc+5wnhh3851UiLdhSaEs5qQ2s7LjOidiM4wx12NeDJrOazhe/noPR3Fb8K WFhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=6hqYwZIMe6fzuXhF+yLf4P5PpHUNaSToHpM8pe3m6rk=; b=WtYPL5AyPv+MC/crr/Ge8fFJt13k0t/Vo5kOZCQWvFDU5xJGcgTNb4L8F4khVfHqvv 85Ua4+lSq3WHXlWApQoDDpMc1e++LbZLdJxlDNJryDhi9kyTBpJxSoMNHs8NUQiFrhot psmHLrnt3Qiog+gMd/BzGLJTedloRKeFVTxZ8pFgRUJIlA7FEBcY5HBabSjVx+ElrIsM SHt6z5+F7K5AsperGNEZ0JC8CTBk9PiSscNx6nXlqr/rrcNsTpS7+VJtP+r2AuqxwlS1 t55yTa5GdEV9MPIiy9mPY7c0j/RhlLC6QyfR1O0Ic0v/kLyNs7guGyF4bsbKbTvTpjjr TMNQ== X-Gm-Message-State: APt69E0SKoJWw05m2iezIZsKzLVEajUjrVZpDqaXrus8NSBCnOxYQgRC fttEwNow+J6VZKYY28ahYOFmSiHNSnBEdUlzUMcYWiQy X-Google-Smtp-Source: AAOMgpduxfaDlYKV4bjI6vwac+GpJX2buXdmk4s05nkPNTchwV+I0VLm3W10lg2V5oHYSvB+8YcYmI7IAiF76fmL3Ik= X-Received: by 2002:aa7:d788:: with SMTP id s8-v6mr23834494edq.228.1530536009103; Mon, 02 Jul 2018 05:53:29 -0700 (PDT) MIME-Version: 1.0 Sender: munro@penski.net Received: by 2002:a50:a1c7:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 05:53:28 -0700 (PDT) X-Originating-IP: [121.73.38.77] From: Thomas Munro Date: Tue, 3 Jul 2018 00:53:28 +1200 X-Google-Sender-Auth: peItxQflbLB3goUlll4txhbunUI Message-ID: Subject: Patching setproctitle() to go faster, for PostgreSQL To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="00000000000023a918057003afda" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 12:53:32 -0000 --00000000000023a918057003afda Content-Type: text/plain; charset="UTF-8" Hi FreeBSD hackers, PostgreSQL's update_process_titles setting, which defaults to on, slows busy databases down quite noticeably on FreeBSD and so a lot of people turn it off. Having that information in ps/top/htop is nice, so I don't like turning it off. It was a rainy Sunday here yesterday so I decided to hack on that. I wrote an experimental patch, attached, that essentially reverts to the ancient syscall-free BSD behaviour (?) on a per-process basis, for processes that are update-heavy. That raises some interesting questions about torn reads, I admit... I didn't see much difference in "pgbench" on my laptop, but on an AWS m4.10xlarge (40 vCPU) machine I could easily see a difference. I think there is probably a contention effect somewhere that gets worse with more concurrency. pgbench -i -s 10 postgres pgbench -T60 -c 40 -j 40 -S -M prepared postgres Stock 11.2, update_process_titles = on: 472873 TPS (default) Stock 11.2, update_process_titles = off: 539391 TPS (~13% faster than default) Patched 11.2, update_process_titles = on: 519733 TPS (~10% faster than default) I'd be grateful for any feedback. Thanks, Thomas Munro --00000000000023a918057003afda Content-Type: application/octet-stream; name="0001-Speed-up-setproctitle-for-frequent-callers.patch" Content-Disposition: attachment; filename="0001-Speed-up-setproctitle-for-frequent-callers.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jj48xgmm0 RnJvbSBlZjkzOGY1YWNmYTM4ZDIwZDVkYTYzMGVkYjE4Mzg3YWRkMTE2MDUwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBUaG9tYXMgTXVucm8gPG11bnJvQGlwOS5vcmc+CkRhdGU6IFR1 ZSwgMyBKdWwgMjAxOCAwMDozMDo0OCArMTIwMApTdWJqZWN0OiBbUEFUQ0hdIFNwZWVkIHVwIHNl dHByb2N0aXRsZSgpIGZvciBmcmVxdWVudCBjYWxsZXJzLgoKU29tZSBhcHBsaWNhdGlvbnMsIG5v dGFibHkgUG9zdGdyZVNRTCwgd2FudCB0byBjYWxsIHNldHByb2N0aXRsZSgpCnZlcnkgb2Z0ZW4u ICBJdCdzIHNsb3cuICBQcm92aWRlIGFuIGFsdGVybmF0aXZlIGNoZWFwIHdheSBvZiB1cGRhdGlu Zwpwcm9jZXNzIHRpdGxlcyB3aXRob3V0IG1ha2luZyBhbnkgc3lzY2FsbHMsIGluc3RlYWQgcmVx dWlyaW5nIG90aGVyCnByb2Nlc3NlcyAodG9wLCBwcyBldGMpIHRvIGRvIGEgYml0IG1vcmUgd29y ayB0byByZXRyaWV2ZSB0aGUgZGF0YS4KVGhpcyB1c2VzIGEgcHJlLWV4aXN0aW5nIGNvZGUgcGF0 aCBpbmhlcml0ZWQgZnJvbSBhbmNpZW50IEJTRCwgd2hpY2gKYWx3YXlzIGRpZCBpdCB0aGF0IHdh eS4gIFN3aXRjaCB0byB0aGUgZmFzdCB1cGRhdGUgc3RyYXRlZ3kgYWZ0ZXIgNQpjYWxscyB0byBz ZXRwcm9jdGl0bGUoKSBmcm9tIGFueSBnaXZlbiBwcm9jZXNzLgoKVGhvbWFzIE11bnJvCi0tLQog bGliL2xpYmMvZ2VuL3NldHByb2N0aXRsZS5jIHwgMjYgKysrKysrKysrKysrKysrKysrKysrLS0t LS0KIHN5cy9rZXJuL2tlcm5fcHJvYy5jICAgICAgICB8IDE5ICsrKysrKysrKysrKysrLS0tLS0K IHVzci5iaW4vdG9wL21hY2hpbmUuYyAgICAgICB8ICAxIC0KIDMgZmlsZXMgY2hhbmdlZCwgMzUg aW5zZXJ0aW9ucygrKSwgMTEgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvZ2Vu L3NldHByb2N0aXRsZS5jIGIvbGliL2xpYmMvZ2VuL3NldHByb2N0aXRsZS5jCmluZGV4IGZkODdj MzUwNzE1Li5mZjJlNTMzYmQ1MyAxMDA2NDQKLS0tIGEvbGliL2xpYmMvZ2VuL3NldHByb2N0aXRs ZS5jCisrKyBiL2xpYi9saWJjL2dlbi9zZXRwcm9jdGl0bGUuYwpAQCAtNTUsNiArNTUsOCBAQCBz dHJ1Y3Qgb2xkX3BzX3N0cmluZ3MgewogCiAjZGVmaW5lIFNQVF9CVUZTSVpFIDIwNDgJLyogZnJv bSBvdGhlciBwYXJ0cyBvZiBzZW5kbWFpbCAqLwogCisjZGVmaW5lIE1BWF9TTE9XX1VQREFURVMg NQkvKiB0aHJlc2hvbGQgZm9yIHN3aXRjaGluZyB0byBmYXN0IHBhdGggKi8KKwogdm9pZAogc2V0 cHJvY3RpdGxlKGNvbnN0IGNoYXIgKmZtdCwgLi4uKQogewpAQCAtNjQsNiArNjYsOCBAQCBzZXRw cm9jdGl0bGUoY29uc3QgY2hhciAqZm10LCAuLi4pCiAJc3RhdGljIGNoYXIgKipvYXJndiwgKmti dWY7CiAJc3RhdGljIGludCBvYXJnYyA9IC0xOwogCXN0YXRpYyBjaGFyICpuYXJndlsyXSA9IHsg TlVMTCwgTlVMTCB9OworCXN0YXRpYyBpbnQgZmFzdF91cGRhdGUgPSAwOworCXN0YXRpYyBpbnQg Y2FsbHMgPSAwOwogCWNoYXIgKipuYXJndnA7CiAJaW50IG5hcmdjOwogCWludCBpOwpAQCAtOTEs NiArOTUsMTYgQEAgc2V0cHJvY3RpdGxlKGNvbnN0IGNoYXIgKmZtdCwgLi4uKQogCWlmIChmbXQp IHsKIAkJYnVmW1NQVF9CVUZTSVpFIC0gMV0gPSAnXDAnOwogCisJCWlmICghZmFzdF91cGRhdGUg JiYgKytjYWxscyA+PSBNQVhfU0xPV19VUERBVEVTKSB7CisJCQkvKiB0ZWxsIHRoZSBrZXJuZWwg dG8gc3RhcnQgbG9va2luZyBpbiB1c2VyLXNwYWNlICovCisJCQlvaWRbMF0gPSBDVExfS0VSTjsK KwkJCW9pZFsxXSA9IEtFUk5fUFJPQzsKKwkJCW9pZFsyXSA9IEtFUk5fUFJPQ19BUkdTOworCQkJ b2lkWzNdID0gZ2V0cGlkKCk7CisJCQlzeXNjdGwob2lkLCA0LCAwLCAwLCAiIiwgMCk7CisJCQlm YXN0X3VwZGF0ZSA9IDE7CisJCX0KKwogCQlpZiAoZm10WzBdID09ICctJykgewogCQkJLyogc2tp cCBwcm9ncmFtIG5hbWUgcHJlZml4ICovCiAJCQlmbXQrKzsKQEAgLTExOSwxMSArMTMzLDEzIEBA IHNldHByb2N0aXRsZShjb25zdCBjaGFyICpmbXQsIC4uLikKIAl2YV9lbmQoYXApOwogCiAJLyog U2V0IHRoZSB0aXRsZSBpbnRvIHRoZSBrZXJuZWwgY2FjaGVkIGNvbW1hbmQgbGluZSAqLwotCW9p ZFswXSA9IENUTF9LRVJOOwotCW9pZFsxXSA9IEtFUk5fUFJPQzsKLQlvaWRbMl0gPSBLRVJOX1BS T0NfQVJHUzsKLQlvaWRbM10gPSBnZXRwaWQoKTsKLQlzeXNjdGwob2lkLCA0LCAwLCAwLCBrYnVm LCBzdHJsZW4oa2J1ZikgKyAxKTsKKwlpZiAoIWZhc3RfdXBkYXRlKSB7CisJCW9pZFswXSA9IENU TF9LRVJOOworCQlvaWRbMV0gPSBLRVJOX1BST0M7CisJCW9pZFsyXSA9IEtFUk5fUFJPQ19BUkdT OworCQlvaWRbM10gPSBnZXRwaWQoKTsKKwkJc3lzY3RsKG9pZCwgNCwgMCwgMCwga2J1Ziwgc3Ry bGVuKGtidWYpICsgMSk7CisJfQogCiAJaWYgKHBzX3N0cmluZ3MgPT0gTlVMTCkgewogCQlsZW4g PSBzaXplb2YodWxfcHNfc3RyaW5ncyk7CmRpZmYgLS1naXQgYS9zeXMva2Vybi9rZXJuX3Byb2Mu YyBiL3N5cy9rZXJuL2tlcm5fcHJvYy5jCmluZGV4IDExZGZkMmY0NGViLi4wMjgwYTJjNzA2YiAx MDA2NDQKLS0tIGEvc3lzL2tlcm4va2Vybl9wcm9jLmMKKysrIGIvc3lzL2tlcm4va2Vybl9wcm9j LmMKQEAgLTE5ODgsMTEgKzE5ODgsMjAgQEAgc3lzY3RsX2tlcm5fcHJvY19hcmdzKFNZU0NUTF9I QU5ETEVSX0FSR1MpCiAKIAlpZiAocmVxLT5uZXdsZW4gPiBwc19hcmdfY2FjaGVfbGltaXQgLSBz aXplb2Yoc3RydWN0IHBhcmdzKSkKIAkJcmV0dXJuIChFTk9NRU0pOwotCW5ld3BhID0gcGFyZ3Nf YWxsb2MocmVxLT5uZXdsZW4pOwotCWVycm9yID0gU1lTQ1RMX0lOKHJlcSwgbmV3cGEtPmFyX2Fy Z3MsIHJlcS0+bmV3bGVuKTsKLQlpZiAoZXJyb3IgIT0gMCkgewotCQlwYXJnc19mcmVlKG5ld3Bh KTsKLQkJcmV0dXJuIChlcnJvcik7CisKKwlpZiAocmVxLT5uZXdsZW4gPT0gMCkgeworCQkvKgor CQkgKiBDbGVhciB0aGUgYXJndW1lbnQgcG9pbnRlciwgc28gdGhhdCB3ZSdsbCBmZXRjaCBhcmd1 bWVudHMKKwkJICogd2l0aCBwcm9jX2dldGFyZ3YoKSB1bnRpbCBmdXJ0aGVyIG5vdGljZS4KKwkJ ICovCisJCW5ld3BhID0gTlVMTDsKKwl9IGVsc2UgeworCQluZXdwYSA9IHBhcmdzX2FsbG9jKHJl cS0+bmV3bGVuKTsKKwkJZXJyb3IgPSBTWVNDVExfSU4ocmVxLCBuZXdwYS0+YXJfYXJncywgcmVx LT5uZXdsZW4pOworCQlpZiAoZXJyb3IgIT0gMCkgeworCQkJcGFyZ3NfZnJlZShuZXdwYSk7CisJ CQlyZXR1cm4gKGVycm9yKTsKKwkJfQogCX0KIAlQUk9DX0xPQ0socCk7CiAJcGEgPSBwLT5wX2Fy Z3M7CmRpZmYgLS1naXQgYS91c3IuYmluL3RvcC9tYWNoaW5lLmMgYi91c3IuYmluL3RvcC9tYWNo aW5lLmMKaW5kZXggYzQ0ZGVjMjY0YTUuLmYwYzdiOGM4NDEwIDEwMDY0NAotLS0gYS91c3IuYmlu L3RvcC9tYWNoaW5lLmMKKysrIGIvdXNyLmJpbi90b3AvbWFjaGluZS5jCkBAIC05NTAsNyArOTUw LDYgQEAgZm9ybWF0X25leHRfcHJvY2VzcyhzdHJ1Y3QgaGFuZGxlICogeGhhbmRsZSwgY2hhciAq KCpnZXRfdXNlcmlkKShpbnQpLCBpbnQgZmxhZ3MKIAkJfQogCX0gZWxzZSB7CiAJCWlmIChwcC0+ a2lfZmxhZyAmIFBfU1lTVEVNIHx8Ci0JCSAgICBwcC0+a2lfYXJncyA9PSBOVUxMIHx8CiAJCSAg ICAoYXJncyA9IGt2bV9nZXRhcmd2KGtkLCBwcCwgY21kbGVuKSkgPT0gTlVMTCB8fAogCQkgICAg ISgqYXJncykpIHsKIAkJCWlmIChwcy50aHJlYWQgJiYgcHAtPmtpX2ZsYWcgJiBQX0hBRFRIUkVB RFMgJiYKLS0gCjIuMTcuMAoK --00000000000023a918057003afda-- From owner-freebsd-hackers@freebsd.org Mon Jul 2 14:08:20 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D457102A6E4 for ; Mon, 2 Jul 2018 14:08:20 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E39A8A3F0 for ; Mon, 2 Jul 2018 14:08:20 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 338BA21C51 for ; Mon, 2 Jul 2018 10:08:13 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Mon, 02 Jul 2018 10:08:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=sMaEHSHbLqwBsAf1p1jUZBhsCjfug JOALo6jojEYPBE=; b=oJeI7UErB1oAnRPqA4WJ7gc0tK64WedEhzgBaNmAi7wLA Gxu/cChLL8ya3MIymLNxsovPIVkDEOs6Psm33IW57YuZVftvlmZIbXDEkGTZ8Z7C WOf46fptGGAxpmZ+DnHKoXzSh22SfHp0ZK55lHQWta1lD5i3wSj02RZNRYtocyvt QL5d1Spt6i+8YAc9xNevo3iZn+4bT7ykY9ihhUxwSifHeVeRFlICPVv+xVKrAiEW gtouugOdX57a4Ny4DsuhJjki8tyx6UXAYSWJtQNj6ufMsAYnsbsbg7TgkGLtqJwe ulTd5+xKKAxyw0tLHpxH9VmgY6qGJA7t5f7PZNluQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id CC42B9E320; Mon, 2 Jul 2018 10:08:12 -0400 (EDT) Message-Id: <1530540492.517203.1427327440.52FB6E20@webmail.messagingengine.com> From: Mark Felder To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c Date: Mon, 02 Jul 2018 09:08:12 -0500 Subject: IPv6 UDP panic on CURRENT X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 14:08:20 -0000 I was having nightly crashes for a while but my watchdog was resetting the server. Finally disabled so I could see the screen. It was happening when my acme (Let's Encrypt) script was running to generate new certificates and uses DNS validation which hits a nameserver hosted on the same box and accessible over IPv6. Fatal trap 12: page fault while in kernel mode cpuid = 11; apic id = 14 fault virtual address = 0xcd fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80e1dc46 stack pointer = 0x28:0xfffffe00005ab760 frame pointer = 0x28:0xfffffe00005ab800 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi1: netisr 0) [ thread pid 12 tid 100086 ] Stopped at ip6_savecontrol_v4+0x26: testb $0x4,ll+0xac(%rax) db> bt Tracing pid 12 tid 100086 td 0xfffff8000381c580 ip6_savecontrol_v4() at ip6_savecontrol_v4+0x26/frame 0xfffffe00005ab800 ip6_savecontrol() at ip6_savecontrol+0x2c/frame 0xfffffe00005ab850 udp6_append() at udp6_append+0xe7/frame 0xfffffe00005ab8a0 udp6_input() at udp6_input+0x4f8/frame 0xfffffe00005ab9c0 ip6_input() at ip6_input+0xdd8/frame 0xfffffe00005abab0 swi_net() at swi_net+0x17b/frame 0xfffffe00005abb20 intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame 0xfffffe00005abb60 ithread_loop() at ithread_loop+0xe7/frame 0xfffffe00005abbb0 fork_exit() at fork_exit+0x83/frame 0xfffffe00005abbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00005abbf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- FreeBSD colo.feld.me 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r335699M: Wed Jun 27 09:09:28 UTC 2018 root@colo.feld.me:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-MLX4 amd64 If there is more information I can collect next time please let me know. -- Mark Felder ports-secteam & portmgr member feld@FreeBSD.org From owner-freebsd-hackers@freebsd.org Mon Jul 2 15:44:14 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E48CD102D61B for ; Mon, 2 Jul 2018 15:44:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4AA2F8E3E2 for ; Mon, 2 Jul 2018 15:44:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w62Fi1Ic024233 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Jul 2018 18:44:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w62Fi1Ic024233 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w62Fi1n5024232; Mon, 2 Jul 2018 18:44:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 2 Jul 2018 18:44:01 +0300 From: Konstantin Belousov To: Thomas Munro Cc: freebsd-hackers@freebsd.org Subject: Re: Patching setproctitle() to go faster, for PostgreSQL Message-ID: <20180702154401.GB2430@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 15:44:14 -0000 On Tue, Jul 03, 2018 at 12:53:28AM +1200, Thomas Munro wrote: > Hi FreeBSD hackers, > > PostgreSQL's update_process_titles setting, which defaults to on, > slows busy databases down quite noticeably on FreeBSD and so a lot of > people turn it off. Having that information in ps/top/htop is nice, > so I don't like turning it off. It was a rainy Sunday here yesterday > so I decided to hack on that. I wrote an experimental patch, > attached, that essentially reverts to the ancient syscall-free BSD > behaviour (?) on a per-process basis, for processes that are > update-heavy. That raises some interesting questions about torn > reads, I admit... > > I didn't see much difference in "pgbench" on my laptop, but on an AWS > m4.10xlarge (40 vCPU) machine I could easily see a difference. I > think there is probably a contention effect somewhere that gets worse > with more concurrency. > > pgbench -i -s 10 postgres > pgbench -T60 -c 40 -j 40 -S -M prepared postgres > > Stock 11.2, update_process_titles = on: 472873 TPS (default) > Stock 11.2, update_process_titles = off: 539391 TPS (~13% faster > than default) > Patched 11.2, update_process_titles = on: 519733 TPS (~10% faster > than default) > > I'd be grateful for any feedback. The kernel chunk looks fine. For the libc, I am not so sure. Why five, why not taking into the account the frequency, what users could do if they want the old behaviour e.g. to see the args in vmcore, and so on. Is modifying posgresql sources acceptable ? If yes, I propose that you add setproctitle_fast(3) (I do not insist on the name). From owner-freebsd-hackers@freebsd.org Tue Jul 3 13:00:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D0B9101A754 for ; Tue, 3 Jul 2018 13:00:47 +0000 (UTC) (envelope-from munro@penski.net) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F5487FD3D for ; Tue, 3 Jul 2018 13:00:46 +0000 (UTC) (envelope-from munro@penski.net) Received: by mail-ed1-x541.google.com with SMTP id g15-v6so1546133edr.12 for ; Tue, 03 Jul 2018 06:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=penski-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ySZaMhapXgPyt6byuR/fYxw7sdTr7/vJDFlaxlwNJvQ=; b=ef3kxlSZo2Y04/gHmPTYASUlEYGAu3j6YHDWRjybeMbs//a9NsJPKG6upvPZESibll tgbbiyZcsLKrg/5zXtxSZc144Z0TgjyNsfuVpoGjARcwzx8LzkNcxCXVwl4M+dmMmlyC CyaZCnsSfo6zFZjxgxK4qWwoplmfDw5tDIKP8NVRVMZ2OzXX5oiLCbDgDvO1m7u8d7I6 ERP6gfM3bL455EveiqyhWp+geTobJ3c6MKCpGL2wVxCPVDkHuq6k6M9zkYvspa/jIrDK Ge6E5D4HULhs7+oPL4bBBWVZ6uK0KBhvqmgGuFJ5RXah6cActwmPzWlctKfr/cVOjnU6 HSOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ySZaMhapXgPyt6byuR/fYxw7sdTr7/vJDFlaxlwNJvQ=; b=lNbr2qRD7B+PPZ8dQZokUZF8Fugz1qy2vdjdzl9BLZ+jDsr2mkkYAADECED5GrmIdj kzcz3oYgqwUX3mMFFOQ/LfyFXxf6xZ3iJiTxMGxDE+vm6OmgzxCjoJ/vBBNaekRkrlK0 OJNkPlVKyygItOL9ITSxIKzaoxjd7ezQCMFJJMHJZgg6VO72n/+6nBM7Lpz4lW6QC9mm QaN+s27rmrDHg0XMdcnstasmOTr93rjAzkt0tLZPswQLAaWIEZpmYBb45rHNRK0/Q1lP wbLQhGUkAdnyrmqgIBvPQ7jHO6wot662PefjMtNnQlBC1ns/tgpqv3ogs1t4WosLG77Q CpsQ== X-Gm-Message-State: APt69E0Fx6MuUe4vWquJeMycUTqe2h+CbaPmOwZzhgQO2b7mHZRIWdVo I250Sy5Rd5dZs59vz4QpBDb3icFzkahKqQ05oAxzmQ== X-Google-Smtp-Source: AAOMgpcURbzgsUUWXCpM6KjMsjaekAHdvAQj+PDW/iQJ9AVXzyPF+u74MaL1YvKi5shoDLkxX6+3yqFvBZ+NgAsGfbg= X-Received: by 2002:a50:c2d9:: with SMTP id u25-v6mr29292365edf.56.1530622845767; Tue, 03 Jul 2018 06:00:45 -0700 (PDT) MIME-Version: 1.0 Sender: munro@penski.net Received: by 2002:a50:a1c7:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 06:00:44 -0700 (PDT) X-Originating-IP: [121.73.38.77] In-Reply-To: <20180702154401.GB2430@kib.kiev.ua> References: <20180702154401.GB2430@kib.kiev.ua> From: Thomas Munro Date: Wed, 4 Jul 2018 01:00:44 +1200 X-Google-Sender-Auth: cNOZ7r2rggtX3-5onsmYzRYwSok Message-ID: Subject: Re: Patching setproctitle() to go faster, for PostgreSQL To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 13:00:47 -0000 On 3 July 2018 at 03:44, Konstantin Belousov wrote: > The kernel chunk looks fine. > > For the libc, I am not so sure. Why five, why not taking into the > account the frequency, what users could do if they want the old > behaviour e.g. to see the args in vmcore, and so on. Ok. > Is modifying posgresql sources acceptable ? If yes, I propose that you add > setproctitle_fast(3) (I do not insist on the name). Ok, here's a first attempt at that: https://reviews.freebsd.org/D16111 Thanks for the feedback! From owner-freebsd-hackers@freebsd.org Wed Jul 4 12:52:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00A471032930 for ; Wed, 4 Jul 2018 12:52:50 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from exch.demig.de (exch.demig.de [130.180.89.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91C2578311 for ; Wed, 4 Jul 2018 12:52:49 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from [192.168.148.248] (port=26306 helo=SRV-FS-2.Demig.intra) by exch.demig.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1fahGt-0005up-12 for freebsd-hackers@freebsd.org; Wed, 04 Jul 2018 14:52:35 +0200 Received: from [192.168.148.215] (192.168.148.215) by SRV-FS-2 (192.168.148.248) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 4 Jul 2018 14:52:24 +0200 X-CTCH-RefID: str=0001.0A0B0208.5B3CC313.00B8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 To: From: Norbert Koch Subject: USB problems with Intel Atom E3825 Message-ID: <27ad8d53-7425-4afa-c6e1-3b4cc5912198@demig.de> Date: Wed, 4 Jul 2018 14:52:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-C2ProcessedOrg: e1e98c77-ec17-4cb1-9b24-fe57656077ed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2018 12:52:50 -0000 Hello. We are investigating to switch our embedded product to a cpu board with an Intel Atom E3825 cpu. Our external hardware is connected through parallel pci and contains slow static rams. Access cycles for reading and writing are at about 1=C2=B5s. When we write to our hardware we see a strange phenomenon: As soon as we continuously write blocks of more than about 24 bytes we see that usb generates a lot of ERR_STALLED messages according to usbdump. FreeBSD identifies an ehci controller. There seems to be no ohci or uhci controller onboard. The exact same happens under FreeBSD 10.3 und 11.2, i386 and amd64 kernel. It never happens when reading the memory even with much bigger block sizes. We never saw any problems with older boards and different chipsets. We contacted the board manufacturer about this and - as we understand - there obviously are known problems with the cpu's pci bridges. But they could not confirm that our problem is related. For testing I downloaded the board manufacturer's embedded linux image (yocto) and found that linux seems to work fine. At least I could not find any problems with usb. So, my idea is that some linux kernel developers know about problems with that chipset and somehow work around it in kernel code. Does anyone here have an idea about this? Are there any kernel switches/options/hints or usb quirks I could possibly try? Thank you in advance. Norbert Koch *********************************************************************** * demig Prozessautomatisierung GmbH * demig Anlagentechnik GmbH * * * * * Anschrift: Haardtstrasse 40 * Haardtstrasse 40 * * D-57076 Siegen * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * Siegen HRB 5532 * * Geschaeftsfuehrer: Joachim Herbst, * Joachim Herbst, * * Winfried Held * Winfried Held * * Telefon: +49 271 772020 * +49 271 772020 * * Telefax: +49 271 74704 * +49 271 74704 * * E-Mail: info@demig.de * at@demig.de * * http://www.demig.de * http://www.demig.de * *********************************************************************** From owner-freebsd-hackers@freebsd.org Thu Jul 5 00:15:01 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 021BF102C2D5 for ; Thu, 5 Jul 2018 00:15:01 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 81AF37ABD2 for ; Thu, 5 Jul 2018 00:15:00 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id w6503jZg051441 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 Jul 2018 20:03:54 -0400 (EDT) (envelope-from george+freebsd@m5p.com) To: FreeBSD Hackers From: George Mitchell Openpgp: preference=signencrypt Autocrypt: addr=george+freebsd@m5p.com; prefer-encrypt=mutual; keydata= xsFNBFgnLnwBEADAJDiBKQX77LFRz9wZW8mz3KvaQol2nIremcws0F1mz/zgFlk6uhQVtwnL wb4XL5LdFwcNE1+QZzPLcbYWoWQlz0lBw1bMuKAgr0S6V2e0+I0DqhKeslVFctcTwtvT6pnK VLZXO/7ZGAaLzG4K5vSPzgoevU+YI/pxNsVCH2UO/c3jQW63uEt25mIZbCF1Pu4jgp4RhIgF ujn877r/j6OwBwjzRUu3E6ADp+U825d+5YCuQMEH0wIPnn9GTpXvfdKdbwOIl2akqXqs4cnk iATWfK3r6D4mvDEj1OPHlTvJYcfic7aOIiAwmx1C1v78GjXOdOOA0SGffNix3C2/8oZUO1+V Aet4MKpUKkduWSvULhIkHNZ5Nu8SIJOqge8pmtHxuNXAMfMrAjMdjPwwBFLsYg3Xa2E2oJwg ehTauwd/EDJFcVCyDCyCAYOi/BH/+XQyxzgDlY9N9qj9tHqhVPI6XK7t8UVffGiZUq4rHp5J RdOToqiTNC6eCJBczhMIW+DuFvWU9e6W708T1dz0Accn6Lrgk4eRIn3GFPBG+TxnpjAqHsbW 607dcnD3YKAqY4e+khczL4EObhe7dC1v2fmZiAC6Ds3WHR11IfqoUgCkIwJ590Ej+ElygJFF XxI82wtEz9hkeLLvItpyEJNVjppViRW+Dgl/U7ypHB3qDgYjgwARAQABzSBHZW9yZ2UgTWl0 Y2hlbGwgPGdlb3JnZUBtNXAuY29tPsLBlwQTAQgAQQIbIwUJCWYBgAULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBDXTOGR5LbCVuZCmV8EREt5vqeH5BQJYWXFRAhkBAAoJEMEREt5vqeH5 SRsQAIb/crcxXyAyeokAuTjN+YXkEFdVv/JrOgNXKdCukXt/UGd3nZTcAzpllytDIvIlPTNI 2/nZ5sm6ymeyVwmvkrM/r3sRUib5ftakJpbv0wn2j+eCGAca8IA2frBUg9bEXKcHRJRQCztG cpousHzOziTCRQ/1NfPcIFBNbQMPUVoQ96cJPvM/XfFGOISKKsSI78skHm6Oazh1hLCQTKvy hNNgVpNP/PHCHMbla1+SNgyn35CUelTh153lnkOhw1XyX6IxY4o5Bhcf3YrxAVcoeHq3FEH0 T3ygAdI14VrZGXXitBAMI78QLB0FiWMoPQ3Oddnoh6tlT4djnsc9IW0Tzk6ozvQL7sKdYgO8 ZlIpkBqQQfpSHzwPu9EkOFggPWB9WtP3IajQ0lt1LovqMug4C8APRC2/1cvi+GUIRwjVsop0 ukhlLTTJd3/S4Muh3s87M4Rdek1xpOiMKjYOVaxmhQQ91oz971zJuJJWpX7uUQiXx9oEwCDW TvI5yEuqYLsMUwx3d2iFTr+HbtlBJmF+Vguyrn/a3vFK8P/TH9fMvNeTdln9SuOOa1SAMMcy czOpBYg9RpzNLshUJVrhKzugT59Rl2wsNQsQCUkzgF3f8cZHJyl+8x6t0nuM9LTkMv13YIXS Mde3UOD2EaBhmeIqvC/adQHxpNudvxM1viFJDnTnzsFNBFgnLnwBEAC7kzsZqjBRPonnr/63 C98FSa3LikvqQWygmPSCC9DsFX/fB0CSXIHTrHQ4a7lXdfZyTZcGdxXN+MC8O8thjvVq6WYm CpyOJ/bq4SxOa9cnQSJ5SP9VCmVoDN/3T4ybXFzLAt756kfQ5jsVuP0m6iQ4z918zhZXk+Mo qdwGjYTxsBD02a7m1aeYafyaI2mZ+vdEy0cDhV4PDXI6ThLNAavTPji6ZrBdH5a4LMg30u8v kkNe0eCKvU+0cWb2VQIeddMhhiGSBE2Dv+A4eNe1VZvoGpLDlYdnoHraVFL2GHNFGymj/uRf 1hja5kW9Rekisqby5SpGABwrFFEs7ABpfYG0IRBKbjjG1Cqdfe/R6ETJFvvNOOpCKPAWeqYf Isxv4OHWTmhKihhIanYWCAe1MDLRRbj7UrOTZeia2WJ4v58xbU5rVQoHI/Tzaq86rXzRWITc 5w+kresMad0zpvQ900BdHc8ATNY2aW/Fr5it5OqMvIW6Y4gc8Z95MkQPVc8vj3WzfxuWtZNK 6Wbv4r6Qbiwg1RpY1JoEIoF4OsZJOVMQaB6ezD7xvaa2eY6nRGtq9SoJxo2qvlSbLlKq8NdH VYHhtTbpQ1NfrEJfv5sLX5W5IpoYww48bFYH67+7r1f/W3voBptSgE7qnYAm6Em9bEAKOQEX 8BXwoa54fn03z6TyhwARAQABwsFkBBgBCAAPBQJYJy58AhsMBQkJZgGAAAoJEMEREt5vqeH5 6PcP+JvrMM7ZM8UlnbrY4Er9psPj3ayllRhQFA9h6GNUKYuSzSxOrPaT96s8KUGMCr4jrn1S WFmeeNLLOgSJmQRicMh6LmnKq6WY6UaOfn7Y9O62NUjXfEI3Bw4ID36YCdQ+CJd14r0YOf4M 5F50bvHV3lbzD9TXZPxecHKC2ZUMBbT37tsckWCLL3lzKMsqQLwBUmgBl1NIUc7gyXxiNyxb 6SPVF1NguDDM438mcg9jSRAyjgAk6POUEM8YIXkw0Gg6HF1tNMJJ1xTMBCLYl6fHTtsxJpf9 yo+Hnw346hqYzXn4ytHJ49Ngcre8uhqM1l8iMpa17tEjfalkc1FWR9/qvoowOKtxpvblsy3a YzeEFgIomhLzISz6IafQ3S7Mt5AFlqwN/qQHx0k2V66GzDG0ngZBPROP1sXSpdJzO0zbJQFn MZE3f+y8vXMcE/MBXR7kAdYYApiEMQzVxy9TdQDU3lGLptcPZ1IOntTNFFrvp5NwsKi+6C9i mXtd5kJ1PwhcJYW3/ov/490l60C5SFUL/RZ/NOW8SHFaPcqlGcqIlexFKbzrMQwmYXo95jWB eZ0Qn+raxCUFZNGiwtusyQGBMcpHVJUanOCNd1z4ZbfmhUjDJKC/7YWDunvaDRSukGiRCl6J s8caqXHiVZjx+s76iWzm6AHRP5jg9D6EtTOrGiE= Subject: Confusing smartd messages Message-ID: Date: Wed, 4 Jul 2018 20:03:46 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yJFBORef2hc2IaiTOsNhSnIGiRSjiYdZN" X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [10.100.0.247]); Wed, 04 Jul 2018 20:03:54 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 00:15:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --yJFBORef2hc2IaiTOsNhSnIGiRSjiYdZN Content-Type: multipart/mixed; boundary="7eAV1XyfzkTFQHoeEvKYsNwNpTjq7xbXZ"; protected-headers="v1" From: George Mitchell To: FreeBSD Hackers Message-ID: Subject: Confusing smartd messages --7eAV1XyfzkTFQHoeEvKYsNwNpTjq7xbXZ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Every thirty minutes, smartd is telling me: Device: /dev/ada1, 2 Currently unreadable (pending) sectors Device: /dev/ada1, 2 Offline uncorrectable sectors smartctl -a /dev/ada1 seems to be reassuring me that everything is fine (SMART overall-health self-assessment test result: PASSED), though it also says: 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 2 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 2 which sounds like it confirms the log message above. The disk is part of a zraid pool whose "zpool status" also says everything is okay. What's the recommended action at this point? -- George --7eAV1XyfzkTFQHoeEvKYsNwNpTjq7xbXZ-- --yJFBORef2hc2IaiTOsNhSnIGiRSjiYdZN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAls9YGkACgkQwRES3m+p 4flvThAAscEvG4mlhPpHDMUHWAXILNIAzefbmbqiqil4xw8pAS9YtdJlYD7g6389 kCFOFZsSn/P8XMVVaGh8z/OwWfvXLvUZy/RmORMCHSm5xn/wuL7WFTE7uT/69lUX VY/pTG9BW37SeLRKgn1SAkD4hKCi4nddXkrJNIrt6Hgm1FQAbuf7L/LGbq933830 SD0STqnkzv0xXZOfZRMJfuGypj5Vypn/+XpXYZ7LOgY0ENubNr3kR/FoHetSGfRq 9VeqZl7nQlU2xXl6vsuVm5715knYsF6QR0JoB83fEddr2dfcRWIG4r5OGAsjO+Fd xkJdicBniHdH/NLF3OEFFXknDUTVXRF4Y44JIPdnEcNGWFDeuFbDYoFkTESjxJ6J R2wZ7nP+LQaECxlXxZ+qNQKVDZS9uFrNJr2esjRme5uoQrX4DiVnCEsvUyFBKgVU 7dolQ0MAWVQjNENchFVMz/MQWaTPyaXRwWPIdFrp2BmiIaIois3EacPF/YxasHhx hym73EErufcQ0nHcpOf0LgvCaPBB1f4kA/XFZoxFQGyJHhxMZ8HwAd1un3Qx7kqk JIoAc1N7HkXQpI1bt8XW6qbFcv7PjuL7DRrRDyqFx40bGQDsYGGXaxLQby8MMn+t sOGW1RXwB4pljBbZi/RZgSPKkdeB33wtzyuGOnXMKF3SQodZFfc= =erYJ -----END PGP SIGNATURE----- --yJFBORef2hc2IaiTOsNhSnIGiRSjiYdZN-- From owner-freebsd-hackers@freebsd.org Thu Jul 5 00:42:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CAC3102EF04 for ; Thu, 5 Jul 2018 00:42:52 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (unknown [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C85D07C015 for ; Thu, 5 Jul 2018 00:42:51 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w650ghQh011643 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Jul 2018 02:42:43 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: george+freebsd@m5p.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w650gZ2o079452 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2018 07:42:35 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Confusing smartd messages To: George Mitchell , FreeBSD Hackers References: From: Eugene Grosbein Message-ID: <5B3D6975.2060508@grosbein.net> Date: Thu, 5 Jul 2018 07:42:29 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 00:42:52 -0000 05.07.2018 7:03, George Mitchell пишет: > Every thirty minutes, smartd is telling me: > > Device: /dev/ada1, 2 Currently unreadable (pending) sectors > Device: /dev/ada1, 2 Offline uncorrectable sectors > > smartctl -a /dev/ada1 seems to be reassuring me that everything is > fine (SMART overall-health self-assessment test result: PASSED), If that would say FAILED, you should be replacing the disk immediately. PASSED does not mean it has no problems, but problems are not fatal (yet). > though it also says: > > 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always > - 2 > 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age > Offline - 2 > > which sounds like it confirms the log message above. The disk is > part of a zraid pool whose "zpool status" also says everything is > okay. What's the recommended action at this point? -- George You need to force the disk performing rewrite of those two bad sectors. There is a possibility they are just an example of "soft bad" and in that event the problem will just disappear without new remaps, that would be best possble case. Or two sectors could happen really bad and remap will "fix" (really hide) the problem, in that case you should be ready for possible increasing number of bad sectors and have a replacement handy. First step is running zpool scrub or even replace the disk and run "dd if=/dev/zero of=/dev/ada1". From owner-freebsd-hackers@freebsd.org Thu Jul 5 00:55:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50C661030047 for ; Thu, 5 Jul 2018 00:55:19 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B724C7C6F7 for ; Thu, 5 Jul 2018 00:55:18 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id w650stes051670 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 Jul 2018 20:55:04 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: Confusing smartd messages To: freebsd-hackers@freebsd.org References: <5B3D6975.2060508@grosbein.net> From: George Mitchell Openpgp: preference=signencrypt Autocrypt: addr=george+freebsd@m5p.com; prefer-encrypt=mutual; keydata= xsFNBFgnLnwBEADAJDiBKQX77LFRz9wZW8mz3KvaQol2nIremcws0F1mz/zgFlk6uhQVtwnL wb4XL5LdFwcNE1+QZzPLcbYWoWQlz0lBw1bMuKAgr0S6V2e0+I0DqhKeslVFctcTwtvT6pnK VLZXO/7ZGAaLzG4K5vSPzgoevU+YI/pxNsVCH2UO/c3jQW63uEt25mIZbCF1Pu4jgp4RhIgF ujn877r/j6OwBwjzRUu3E6ADp+U825d+5YCuQMEH0wIPnn9GTpXvfdKdbwOIl2akqXqs4cnk iATWfK3r6D4mvDEj1OPHlTvJYcfic7aOIiAwmx1C1v78GjXOdOOA0SGffNix3C2/8oZUO1+V Aet4MKpUKkduWSvULhIkHNZ5Nu8SIJOqge8pmtHxuNXAMfMrAjMdjPwwBFLsYg3Xa2E2oJwg ehTauwd/EDJFcVCyDCyCAYOi/BH/+XQyxzgDlY9N9qj9tHqhVPI6XK7t8UVffGiZUq4rHp5J RdOToqiTNC6eCJBczhMIW+DuFvWU9e6W708T1dz0Accn6Lrgk4eRIn3GFPBG+TxnpjAqHsbW 607dcnD3YKAqY4e+khczL4EObhe7dC1v2fmZiAC6Ds3WHR11IfqoUgCkIwJ590Ej+ElygJFF XxI82wtEz9hkeLLvItpyEJNVjppViRW+Dgl/U7ypHB3qDgYjgwARAQABzSBHZW9yZ2UgTWl0 Y2hlbGwgPGdlb3JnZUBtNXAuY29tPsLBlwQTAQgAQQIbIwUJCWYBgAULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBDXTOGR5LbCVuZCmV8EREt5vqeH5BQJYWXFRAhkBAAoJEMEREt5vqeH5 SRsQAIb/crcxXyAyeokAuTjN+YXkEFdVv/JrOgNXKdCukXt/UGd3nZTcAzpllytDIvIlPTNI 2/nZ5sm6ymeyVwmvkrM/r3sRUib5ftakJpbv0wn2j+eCGAca8IA2frBUg9bEXKcHRJRQCztG cpousHzOziTCRQ/1NfPcIFBNbQMPUVoQ96cJPvM/XfFGOISKKsSI78skHm6Oazh1hLCQTKvy hNNgVpNP/PHCHMbla1+SNgyn35CUelTh153lnkOhw1XyX6IxY4o5Bhcf3YrxAVcoeHq3FEH0 T3ygAdI14VrZGXXitBAMI78QLB0FiWMoPQ3Oddnoh6tlT4djnsc9IW0Tzk6ozvQL7sKdYgO8 ZlIpkBqQQfpSHzwPu9EkOFggPWB9WtP3IajQ0lt1LovqMug4C8APRC2/1cvi+GUIRwjVsop0 ukhlLTTJd3/S4Muh3s87M4Rdek1xpOiMKjYOVaxmhQQ91oz971zJuJJWpX7uUQiXx9oEwCDW TvI5yEuqYLsMUwx3d2iFTr+HbtlBJmF+Vguyrn/a3vFK8P/TH9fMvNeTdln9SuOOa1SAMMcy czOpBYg9RpzNLshUJVrhKzugT59Rl2wsNQsQCUkzgF3f8cZHJyl+8x6t0nuM9LTkMv13YIXS Mde3UOD2EaBhmeIqvC/adQHxpNudvxM1viFJDnTnzsFNBFgnLnwBEAC7kzsZqjBRPonnr/63 C98FSa3LikvqQWygmPSCC9DsFX/fB0CSXIHTrHQ4a7lXdfZyTZcGdxXN+MC8O8thjvVq6WYm CpyOJ/bq4SxOa9cnQSJ5SP9VCmVoDN/3T4ybXFzLAt756kfQ5jsVuP0m6iQ4z918zhZXk+Mo qdwGjYTxsBD02a7m1aeYafyaI2mZ+vdEy0cDhV4PDXI6ThLNAavTPji6ZrBdH5a4LMg30u8v kkNe0eCKvU+0cWb2VQIeddMhhiGSBE2Dv+A4eNe1VZvoGpLDlYdnoHraVFL2GHNFGymj/uRf 1hja5kW9Rekisqby5SpGABwrFFEs7ABpfYG0IRBKbjjG1Cqdfe/R6ETJFvvNOOpCKPAWeqYf Isxv4OHWTmhKihhIanYWCAe1MDLRRbj7UrOTZeia2WJ4v58xbU5rVQoHI/Tzaq86rXzRWITc 5w+kresMad0zpvQ900BdHc8ATNY2aW/Fr5it5OqMvIW6Y4gc8Z95MkQPVc8vj3WzfxuWtZNK 6Wbv4r6Qbiwg1RpY1JoEIoF4OsZJOVMQaB6ezD7xvaa2eY6nRGtq9SoJxo2qvlSbLlKq8NdH VYHhtTbpQ1NfrEJfv5sLX5W5IpoYww48bFYH67+7r1f/W3voBptSgE7qnYAm6Em9bEAKOQEX 8BXwoa54fn03z6TyhwARAQABwsFkBBgBCAAPBQJYJy58AhsMBQkJZgGAAAoJEMEREt5vqeH5 6PcP+JvrMM7ZM8UlnbrY4Er9psPj3ayllRhQFA9h6GNUKYuSzSxOrPaT96s8KUGMCr4jrn1S WFmeeNLLOgSJmQRicMh6LmnKq6WY6UaOfn7Y9O62NUjXfEI3Bw4ID36YCdQ+CJd14r0YOf4M 5F50bvHV3lbzD9TXZPxecHKC2ZUMBbT37tsckWCLL3lzKMsqQLwBUmgBl1NIUc7gyXxiNyxb 6SPVF1NguDDM438mcg9jSRAyjgAk6POUEM8YIXkw0Gg6HF1tNMJJ1xTMBCLYl6fHTtsxJpf9 yo+Hnw346hqYzXn4ytHJ49Ngcre8uhqM1l8iMpa17tEjfalkc1FWR9/qvoowOKtxpvblsy3a YzeEFgIomhLzISz6IafQ3S7Mt5AFlqwN/qQHx0k2V66GzDG0ngZBPROP1sXSpdJzO0zbJQFn MZE3f+y8vXMcE/MBXR7kAdYYApiEMQzVxy9TdQDU3lGLptcPZ1IOntTNFFrvp5NwsKi+6C9i mXtd5kJ1PwhcJYW3/ov/490l60C5SFUL/RZ/NOW8SHFaPcqlGcqIlexFKbzrMQwmYXo95jWB eZ0Qn+raxCUFZNGiwtusyQGBMcpHVJUanOCNd1z4ZbfmhUjDJKC/7YWDunvaDRSukGiRCl6J s8caqXHiVZjx+s76iWzm6AHRP5jg9D6EtTOrGiE= Message-ID: <17c1cb78-f2f0-ff13-6425-8ac634ddaa56@m5p.com> Date: Wed, 4 Jul 2018 20:54:57 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5B3D6975.2060508@grosbein.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2II8fqPNB6TmBEshN83NVpW0gzsFcE8L9" X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [10.100.0.247]); Wed, 04 Jul 2018 20:55:05 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 00:55:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2II8fqPNB6TmBEshN83NVpW0gzsFcE8L9 Content-Type: multipart/mixed; boundary="ggSpYrsE1Z96qgC6aPrId9clGlNTQT7CW"; protected-headers="v1" From: George Mitchell To: freebsd-hackers@freebsd.org Message-ID: <17c1cb78-f2f0-ff13-6425-8ac634ddaa56@m5p.com> Subject: Re: Confusing smartd messages References: <5B3D6975.2060508@grosbein.net> In-Reply-To: <5B3D6975.2060508@grosbein.net> --ggSpYrsE1Z96qgC6aPrId9clGlNTQT7CW Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/04/18 20:42, Eugene Grosbein wrote: > 05.07.2018 7:03, George Mitchell =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> [...] What's the recommended action at this point? -- George >=20 > You need to force the disk performing rewrite of those two bad sectors.= > There is a possibility they are just an example of "soft bad" and in th= at event > the problem will just disappear without new remaps, that would be best = possble case. >=20 > Or two sectors could happen really bad and remap will "fix" (really hid= e) the problem, > in that case you should be ready for possible increasing number of bad = sectors > and have a replacement handy. >=20 > First step is running zpool scrub or even replace the disk and run "dd = if=3D/dev/zero of=3D/dev/ada1". > [...] I'll start with zpool scrub. What's the magic command (if any) to force a rewrite of the sectors? -- George --ggSpYrsE1Z96qgC6aPrId9clGlNTQT7CW-- --2II8fqPNB6TmBEshN83NVpW0gzsFcE8L9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAls9bGEACgkQwRES3m+p 4fnXPg/+Jj57dSfSpoRuDov5eLqrEcCm3rGdMGJqTCfO0tmifRFKmPyLeQLLuuUg FgXxkkec6sjWiTiYy2cncwuMB+i2TJZxTYk1krlWgGWqN96veAqonr3WBPGzhwT7 M/5/oZ8UrxwwtrSovyFknDh+39fdL7bkDnlaTcnbZEF67RUL3v7rvsh9THM+i+f6 YaaGGHcnCPPZPDifHKcVF7xwgOQCD8pYztAIZnYd95rFlQZ2zF58Jhp8jC0V/Q0R IYk2VOJE8y2QQORwwphoC+kf/vAShsFV2StSnQKl9Ot2aMntmKZ+ES4ORKibq0Mu WDIekkTYjQkHHXSyoCc/CTwRc3LcU95OKci7pLwYqrBrIWAdIb/RQ+X9kN+qc6/1 Am8mggTTRCv/EcmTkAmQhgSjXeq8Rnj6zGSre+0DItE5wYOvTYNUhHyv1vDfV5gx H2aq7MaBjI7bF4v0hUvwhwvulnkTVGm/a1O0c3+bMSaqZ0sr/MpaMH8zIOwadXHG EsbmMvslMHgA3ogcpyd9Le1DBsvSuQ8cfwjTvZj6d162UOZLAvHV8MztOGNVCw/C uSRDnGh3h9x3OfEWjo4FJNQndz9rlunq6YqQWwjW4ZpCoi4dYOPvxKFTk0tt4UH5 tMaWlL++pmlSdcfviVs1TZPnWpsBFI7rDg576g54hA5VaHi3X0Q= =SqyB -----END PGP SIGNATURE----- --2II8fqPNB6TmBEshN83NVpW0gzsFcE8L9-- From owner-freebsd-hackers@freebsd.org Thu Jul 5 01:06:01 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30EC41031009 for ; Thu, 5 Jul 2018 01:06:01 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 958B27D09A for ; Thu, 5 Jul 2018 01:06:00 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w6515u6K045568; Wed, 4 Jul 2018 18:05:56 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w6515uRD045567; Wed, 4 Jul 2018 18:05:56 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807050105.w6515uRD045567@pdx.rh.CN85.dnsmgr.net> Subject: Re: Confusing smartd messages In-Reply-To: <5B3D6975.2060508@grosbein.net> To: Eugene Grosbein Date: Wed, 4 Jul 2018 18:05:56 -0700 (PDT) CC: George Mitchell , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 01:06:01 -0000 [ Charset UTF-8 unsupported, converting... ] > 05.07.2018 7:03, George Mitchell ?????: > > Every thirty minutes, smartd is telling me: > > > > Device: /dev/ada1, 2 Currently unreadable (pending) sectors > > Device: /dev/ada1, 2 Offline uncorrectable sectors > > > > smartctl -a /dev/ada1 seems to be reassuring me that everything is > > fine (SMART overall-health self-assessment test result: PASSED), > > If that would say FAILED, you should be replacing the disk immediately. > PASSED does not mean it has no problems, but problems are not fatal (yet). > > > though it also says: > > > > 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always > > - 2 > > 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age > > Offline - 2 > > > > which sounds like it confirms the log message above. The disk is > > part of a zraid pool whose "zpool status" also says everything is > > okay. What's the recommended action at this point? -- George > > You need to force the disk performing rewrite of those two bad sectors. > There is a possibility they are just an example of "soft bad" and in that event > the problem will just disappear without new remaps, that would be best possble case. > > Or two sectors could happen really bad and remap will "fix" (really hide) the problem, > in that case you should be ready for possible increasing number of bad sectors > and have a replacement handy. > > First step is running zpool scrub or even replace the disk and run "dd if=/dev/zero of=/dev/ada1". It would be really nice if we had a way to tell ZFS to do the equivelent of: dd if=/dev/ada1 of=/dev/ada1 bs=128k conv=noerror,sync in some type of lowlevel scrub operation, with proper locking which could easily repair most of these Pending Sector errors, which are actually fairly common in the first couple 100 hours of drive operation. It would of also been nice if the ata standard would of made a way to get the LBA of pending sectors so that a very quick rewrite attempt could be done to fix them. IIRC this info is avalible, but in a vendor specific way. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Jul 5 01:07:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C14B010312CA for ; Thu, 5 Jul 2018 01:07:58 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F7797D1F7 for ; Thu, 5 Jul 2018 01:07:58 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id askLfpR5POFAwaskMfNSTc; Wed, 04 Jul 2018 19:07:51 -0600 X-Authority-Analysis: v=2.3 cv=Y4XWTCWN c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=8nJEP1OIZ-IA:10 a=R9QF1RCXAYgA:10 a=H0GPC0OhAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=P1dHc4KmPYKYDttPTekA:9 a=jDGSrDZBlbaO7yn5:21 a=IpsP_A-6p9QnD2Ye:21 a=wPNLvfGTeEIA:10 a=KczGKrPSgCPlefTG41c3:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 26A684F2; Wed, 4 Jul 2018 18:07:45 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w6517iRA056523; Wed, 4 Jul 2018 18:07:44 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w6517hug056380; Wed, 4 Jul 2018 18:07:43 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201807050107.w6517hug056380@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Eugene Grosbein cc: George Mitchell , FreeBSD Hackers Subject: Re: Confusing smartd messages In-Reply-To: Message from Eugene Grosbein of "Thu, 05 Jul 2018 07:42:29 +0700." <5B3D6975.2060508@grosbein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 04 Jul 2018 18:07:43 -0700 X-CMAE-Envelope: MS4wfFTuAo3QXFFHKzsq67ZDls9WpOQlI+FwVZylD2r7HqUZu6PJ6BHmzoltR8TG/ZBlZI4yGjqUq6HtCyOt7sMnnbfcLzZvv/ZB/Wqivji0lta1b19N+k3P xDeVkQtRveqZJHBNmqHKj7meeFaaltMj0B4pYoytPfPC6fciHGUBxsultcOmr7kUlOTsCqaheGx8XivZBN3BmD2kY/HA8sidMLlFSv2AlJdWz0U+dHUEF/H3 hY9x9O4dbbp5XjHYzioHsQ== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 01:07:59 -0000 In message <5B3D6975.2060508@grosbein.net>, Eugene Grosbein writes: > 05.07.2018 7:03, George Mitchell пишет: > > Every thirty minutes, smartd is telling me: > > > > Device: /dev/ada1, 2 Currently unreadable (pending) sectors > > Device: /dev/ada1, 2 Offline uncorrectable sectors > > > > smartctl -a /dev/ada1 seems to be reassuring me that everything is > > fine (SMART overall-health self-assessment test result: PASSED), > > If that would say FAILED, you should be replacing the disk immediately. > PASSED does not mean it has no problems, but problems are not fatal (yet). > > > though it also says: > > > > 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always > > - 2 > > 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age > > Offline - 2 > > > > which sounds like it confirms the log message above. The disk is > > part of a zraid pool whose "zpool status" also says everything is > > okay. What's the recommended action at this point? -- George > > You need to force the disk performing rewrite of those two bad sectors. > There is a possibility they are just an example of "soft bad" and in that eve > nt > the problem will just disappear without new remaps, that would be best possbl > e case. > > Or two sectors could happen really bad and remap will "fix" (really hide) the > problem, > in that case you should be ready for possible increasing number of bad sector > s > and have a replacement handy. > > First step is running zpool scrub or even replace the disk and run "dd if=/de > v/zero of=/dev/ada1". A better option would be to determine which blocks had the issue. Then use dd if=/dev/ada1 of=/dev/ada1 iseek= oseek= count= Alternatively you can dd_rescue -d -s -S /dev/ada1 /dev/ada1 Failing that dd_rescue the whole device. Make sure your zpool has been exported. If "repairing" a UFS root filesystem, use single user mode or the machine will panic, though no loss of data, just a PITA. This avoids loss of data. Ideally your best bet would be to back up the data and write zeros, ones, and some random data. This "exercises" each sector such that there is less chance of having the same magnetic transitions interfering with each other. The reason is that an actuator never writes to the same area of disk because of variations in actuator movement. Phantom transitions have a slight chance of having effect. Finally, if after going through this exercise the bad sectors are not remapped or clear up only to show up as bad later then replace the disk. Of course if your data is critically important then replace the disk right away. You don't know how quickly your disk is aging or deteriorating until it's too late. On the positive side, I've been able to resurrect many disks this way. If in a critical server (my main machine or firewall) I replace the disk immediately, moving the one experiencing errors to a testbed machine, one I don't mind losing data as it's easily reproduced or replicated from the main machine. Many times the flaky disks don't complain while in my testbed for years before dying. YMMV -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Thu Jul 5 01:09:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62971103161D for ; Thu, 5 Jul 2018 01:09:23 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (unknown [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DD8297D3A4 for ; Thu, 5 Jul 2018 01:09:22 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w6519GNt012473 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Jul 2018 03:09:16 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: george+freebsd@m5p.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w6519C79079686 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2018 08:09:12 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Confusing smartd messages To: George Mitchell , freebsd-hackers@freebsd.org References: <5B3D6975.2060508@grosbein.net> <17c1cb78-f2f0-ff13-6425-8ac634ddaa56@m5p.com> From: Eugene Grosbein Message-ID: <5B3D6FB3.5010908@grosbein.net> Date: Thu, 5 Jul 2018 08:09:07 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <17c1cb78-f2f0-ff13-6425-8ac634ddaa56@m5p.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 01:09:23 -0000 05.07.2018 7:54, George Mitchell write: >> First step is running zpool scrub or even replace the disk and run "dd if=/dev/zero of=/dev/ada1". >> [...] > > I'll start with zpool scrub. What's the magic command (if any) to > force a rewrite of the sectors? -- George Modern HDDs are embedded computers theyselves with their own CPU, RAM, flash memory and special operating system (firmware) running inside. They have spare load of generally unused and hidden sectors also. When firmware sees write error due to really bad spot on magnetic part of disk making a sector "bad", it performs a remap by means of internal translation table for LBAs to use one of hidden sectors instead of bad one. And until the amount of hidden sectors is not exhausted (there are can be over a thousand of them), the disk keeps running nearly fine. Sometimes the sector just gets wrong checksum written due to power failure, hence read errors due to "mismatched" checksum. Overwrite corrects such "soft bad" error without need to remap. Eugene P.S. your smtp server (MX) rejects my direct mail to you with "550 5.7.1 Access denied" errors. From owner-freebsd-hackers@freebsd.org Thu Jul 5 01:14:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F40010320D5 for ; Thu, 5 Jul 2018 01:14:00 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (unknown [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E57A77DA9B for ; Thu, 5 Jul 2018 01:13:59 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w651Dr56012533 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Jul 2018 03:13:53 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-rwg@pdx.rh.CN85.dnsmgr.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w651DoTm079728 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2018 08:13:50 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Confusing smartd messages To: "Rodney W. Grimes" References: <201807050105.w6515uRD045567@pdx.rh.CN85.dnsmgr.net> Cc: George Mitchell , FreeBSD Hackers From: Eugene Grosbein Message-ID: <5B3D70C8.60301@grosbein.net> Date: Thu, 5 Jul 2018 08:13:44 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201807050105.w6515uRD045567@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 01:14:00 -0000 05.07.2018 8:05, Rodney W. Grimes wrote: > It would of also been nice if the ata standard would of made a way > to get the LBA of pending sectors so that a very quick rewrite attempt > could be done to fix them. IIRC this info is avalible, but in a vendor > specific way. "smartctl -t long" reveals LBA of first pending sector. From owner-freebsd-hackers@freebsd.org Thu Jul 5 01:41:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 675071034EE6 for ; Thu, 5 Jul 2018 01:41:58 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DAAA27F69A for ; Thu, 5 Jul 2018 01:41:57 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id w651fXrC051904 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 Jul 2018 21:41:43 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: Confusing smartd messages To: freebsd-hackers@freebsd.org References: <201807050105.w6515uRD045567@pdx.rh.CN85.dnsmgr.net> <5B3D70C8.60301@grosbein.net> From: George Mitchell Openpgp: preference=signencrypt Autocrypt: addr=george+freebsd@m5p.com; prefer-encrypt=mutual; keydata= xsFNBFgnLnwBEADAJDiBKQX77LFRz9wZW8mz3KvaQol2nIremcws0F1mz/zgFlk6uhQVtwnL wb4XL5LdFwcNE1+QZzPLcbYWoWQlz0lBw1bMuKAgr0S6V2e0+I0DqhKeslVFctcTwtvT6pnK VLZXO/7ZGAaLzG4K5vSPzgoevU+YI/pxNsVCH2UO/c3jQW63uEt25mIZbCF1Pu4jgp4RhIgF ujn877r/j6OwBwjzRUu3E6ADp+U825d+5YCuQMEH0wIPnn9GTpXvfdKdbwOIl2akqXqs4cnk iATWfK3r6D4mvDEj1OPHlTvJYcfic7aOIiAwmx1C1v78GjXOdOOA0SGffNix3C2/8oZUO1+V Aet4MKpUKkduWSvULhIkHNZ5Nu8SIJOqge8pmtHxuNXAMfMrAjMdjPwwBFLsYg3Xa2E2oJwg ehTauwd/EDJFcVCyDCyCAYOi/BH/+XQyxzgDlY9N9qj9tHqhVPI6XK7t8UVffGiZUq4rHp5J RdOToqiTNC6eCJBczhMIW+DuFvWU9e6W708T1dz0Accn6Lrgk4eRIn3GFPBG+TxnpjAqHsbW 607dcnD3YKAqY4e+khczL4EObhe7dC1v2fmZiAC6Ds3WHR11IfqoUgCkIwJ590Ej+ElygJFF XxI82wtEz9hkeLLvItpyEJNVjppViRW+Dgl/U7ypHB3qDgYjgwARAQABzSBHZW9yZ2UgTWl0 Y2hlbGwgPGdlb3JnZUBtNXAuY29tPsLBlwQTAQgAQQIbIwUJCWYBgAULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBDXTOGR5LbCVuZCmV8EREt5vqeH5BQJYWXFRAhkBAAoJEMEREt5vqeH5 SRsQAIb/crcxXyAyeokAuTjN+YXkEFdVv/JrOgNXKdCukXt/UGd3nZTcAzpllytDIvIlPTNI 2/nZ5sm6ymeyVwmvkrM/r3sRUib5ftakJpbv0wn2j+eCGAca8IA2frBUg9bEXKcHRJRQCztG cpousHzOziTCRQ/1NfPcIFBNbQMPUVoQ96cJPvM/XfFGOISKKsSI78skHm6Oazh1hLCQTKvy hNNgVpNP/PHCHMbla1+SNgyn35CUelTh153lnkOhw1XyX6IxY4o5Bhcf3YrxAVcoeHq3FEH0 T3ygAdI14VrZGXXitBAMI78QLB0FiWMoPQ3Oddnoh6tlT4djnsc9IW0Tzk6ozvQL7sKdYgO8 ZlIpkBqQQfpSHzwPu9EkOFggPWB9WtP3IajQ0lt1LovqMug4C8APRC2/1cvi+GUIRwjVsop0 ukhlLTTJd3/S4Muh3s87M4Rdek1xpOiMKjYOVaxmhQQ91oz971zJuJJWpX7uUQiXx9oEwCDW TvI5yEuqYLsMUwx3d2iFTr+HbtlBJmF+Vguyrn/a3vFK8P/TH9fMvNeTdln9SuOOa1SAMMcy czOpBYg9RpzNLshUJVrhKzugT59Rl2wsNQsQCUkzgF3f8cZHJyl+8x6t0nuM9LTkMv13YIXS Mde3UOD2EaBhmeIqvC/adQHxpNudvxM1viFJDnTnzsFNBFgnLnwBEAC7kzsZqjBRPonnr/63 C98FSa3LikvqQWygmPSCC9DsFX/fB0CSXIHTrHQ4a7lXdfZyTZcGdxXN+MC8O8thjvVq6WYm CpyOJ/bq4SxOa9cnQSJ5SP9VCmVoDN/3T4ybXFzLAt756kfQ5jsVuP0m6iQ4z918zhZXk+Mo qdwGjYTxsBD02a7m1aeYafyaI2mZ+vdEy0cDhV4PDXI6ThLNAavTPji6ZrBdH5a4LMg30u8v kkNe0eCKvU+0cWb2VQIeddMhhiGSBE2Dv+A4eNe1VZvoGpLDlYdnoHraVFL2GHNFGymj/uRf 1hja5kW9Rekisqby5SpGABwrFFEs7ABpfYG0IRBKbjjG1Cqdfe/R6ETJFvvNOOpCKPAWeqYf Isxv4OHWTmhKihhIanYWCAe1MDLRRbj7UrOTZeia2WJ4v58xbU5rVQoHI/Tzaq86rXzRWITc 5w+kresMad0zpvQ900BdHc8ATNY2aW/Fr5it5OqMvIW6Y4gc8Z95MkQPVc8vj3WzfxuWtZNK 6Wbv4r6Qbiwg1RpY1JoEIoF4OsZJOVMQaB6ezD7xvaa2eY6nRGtq9SoJxo2qvlSbLlKq8NdH VYHhtTbpQ1NfrEJfv5sLX5W5IpoYww48bFYH67+7r1f/W3voBptSgE7qnYAm6Em9bEAKOQEX 8BXwoa54fn03z6TyhwARAQABwsFkBBgBCAAPBQJYJy58AhsMBQkJZgGAAAoJEMEREt5vqeH5 6PcP+JvrMM7ZM8UlnbrY4Er9psPj3ayllRhQFA9h6GNUKYuSzSxOrPaT96s8KUGMCr4jrn1S WFmeeNLLOgSJmQRicMh6LmnKq6WY6UaOfn7Y9O62NUjXfEI3Bw4ID36YCdQ+CJd14r0YOf4M 5F50bvHV3lbzD9TXZPxecHKC2ZUMBbT37tsckWCLL3lzKMsqQLwBUmgBl1NIUc7gyXxiNyxb 6SPVF1NguDDM438mcg9jSRAyjgAk6POUEM8YIXkw0Gg6HF1tNMJJ1xTMBCLYl6fHTtsxJpf9 yo+Hnw346hqYzXn4ytHJ49Ngcre8uhqM1l8iMpa17tEjfalkc1FWR9/qvoowOKtxpvblsy3a YzeEFgIomhLzISz6IafQ3S7Mt5AFlqwN/qQHx0k2V66GzDG0ngZBPROP1sXSpdJzO0zbJQFn MZE3f+y8vXMcE/MBXR7kAdYYApiEMQzVxy9TdQDU3lGLptcPZ1IOntTNFFrvp5NwsKi+6C9i mXtd5kJ1PwhcJYW3/ov/490l60C5SFUL/RZ/NOW8SHFaPcqlGcqIlexFKbzrMQwmYXo95jWB eZ0Qn+raxCUFZNGiwtusyQGBMcpHVJUanOCNd1z4ZbfmhUjDJKC/7YWDunvaDRSukGiRCl6J s8caqXHiVZjx+s76iWzm6AHRP5jg9D6EtTOrGiE= Message-ID: <53c3dd92-d408-8d05-9746-d6b0a5a32b5b@m5p.com> Date: Wed, 4 Jul 2018 21:41:34 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <5B3D70C8.60301@grosbein.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Riv9HXdlHWwn6IgR6PrNVZ8A6panjjGDu" X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [10.100.0.247]); Wed, 04 Jul 2018 21:41:44 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 01:41:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Riv9HXdlHWwn6IgR6PrNVZ8A6panjjGDu Content-Type: multipart/mixed; boundary="A3HnHrdxxhbvltjTCwJN8LcTMa7nfsgmi"; protected-headers="v1" From: George Mitchell To: freebsd-hackers@freebsd.org Message-ID: <53c3dd92-d408-8d05-9746-d6b0a5a32b5b@m5p.com> Subject: Re: Confusing smartd messages References: <201807050105.w6515uRD045567@pdx.rh.CN85.dnsmgr.net> <5B3D70C8.60301@grosbein.net> In-Reply-To: <5B3D70C8.60301@grosbein.net> --A3HnHrdxxhbvltjTCwJN8LcTMa7nfsgmi Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/04/18 21:13, Eugene Grosbein wrote: > 05.07.2018 8:05, Rodney W. Grimes wrote: > >> It would of also been nice if the ata standard would of made a way >> to get the LBA of pending sectors so that a very quick rewrite attempt= >> could be done to fix them. IIRC this info is avalible, but in a vendo= r >> specific way. > > "smartctl -t long" reveals LBA of first pending sector. > [...] "zpool scrub" completed with no apparent problem, and I've just started "smartctl -t long", which claims it will finish in 398 minutes. -- George --A3HnHrdxxhbvltjTCwJN8LcTMa7nfsgmi-- --Riv9HXdlHWwn6IgR6PrNVZ8A6panjjGDu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAls9d04ACgkQwRES3m+p 4fncMxAAkPUe/3n15S2agnVAFGuSzCZolikRsPIf0gbWP+xtoKUggxXU7jasAKUZ cA7oC9ObfFpRI8HeEuhjW6A5XsFcUsoO7/lMSNndt7dkFRySYbpULm9IryDVaBOt reF0TDbu/r3Dd6unn8pYkE0tOK5nX8j2qUu76N+O8MYai9XmErB2iuEWtnlIUGOR uZQIriY5fd23CUrrQ5zY32wVtfhtKDKHYuI9G7NhNvQH8Xx5bVV/Rh1NYLSKjNXE rMCxVTEwNcwoe6KY2s6PwMImPiSFcGuclgtuPItjiwnU4KauzSCAyiaXM2QBgnvY pvv1OyfjiKrdsgH0ymW22EXFBZ6VaRDijYAKH0AMtvH8ob2VL/1htb4/usOlUdGE xvuDuXvpkWrbM/oydNkZDEsOneGyWCY11als4a6HRRweBUnWxyg6++ThIqx0tMfq EzBITEGRDVPN9tJdOTwa524WfayOwhY+M24Wtf25eNTAmGzm6g/H6oPoll8D2NXs ym9JXyWEtZSpMGTp1sVjl5y8p9Y/Uwrnlu8juNJOHLxWclZlozweQxlkODFekknl ItFz0n8MhY2uGLa4LYMIpuZLqnVvy788RSnaEqHRZtUXkV9Xe5XAxAmtcOBOEbTw TV7AuH0FC9uiRz5eZ/Rfy3W2Kf7BHMeQQ3aEc9uAp/ikFgL/pog= =DuQc -----END PGP SIGNATURE----- --Riv9HXdlHWwn6IgR6PrNVZ8A6panjjGDu-- From owner-freebsd-hackers@freebsd.org Thu Jul 5 01:42:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EA351034FED for ; Thu, 5 Jul 2018 01:42:47 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BEEF67F8BF for ; Thu, 5 Jul 2018 01:42:46 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id w651gNQa051908 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 4 Jul 2018 21:42:33 -0400 (EDT) (envelope-from george+freebsd@m5p.com) Subject: Re: Confusing smartd messages To: freebsd-hackers@freebsd.org References: <201807050107.w6517hug056380@slippy.cwsent.com> From: George Mitchell Openpgp: preference=signencrypt Autocrypt: addr=george+freebsd@m5p.com; prefer-encrypt=mutual; keydata= xsFNBFgnLnwBEADAJDiBKQX77LFRz9wZW8mz3KvaQol2nIremcws0F1mz/zgFlk6uhQVtwnL wb4XL5LdFwcNE1+QZzPLcbYWoWQlz0lBw1bMuKAgr0S6V2e0+I0DqhKeslVFctcTwtvT6pnK VLZXO/7ZGAaLzG4K5vSPzgoevU+YI/pxNsVCH2UO/c3jQW63uEt25mIZbCF1Pu4jgp4RhIgF ujn877r/j6OwBwjzRUu3E6ADp+U825d+5YCuQMEH0wIPnn9GTpXvfdKdbwOIl2akqXqs4cnk iATWfK3r6D4mvDEj1OPHlTvJYcfic7aOIiAwmx1C1v78GjXOdOOA0SGffNix3C2/8oZUO1+V Aet4MKpUKkduWSvULhIkHNZ5Nu8SIJOqge8pmtHxuNXAMfMrAjMdjPwwBFLsYg3Xa2E2oJwg ehTauwd/EDJFcVCyDCyCAYOi/BH/+XQyxzgDlY9N9qj9tHqhVPI6XK7t8UVffGiZUq4rHp5J RdOToqiTNC6eCJBczhMIW+DuFvWU9e6W708T1dz0Accn6Lrgk4eRIn3GFPBG+TxnpjAqHsbW 607dcnD3YKAqY4e+khczL4EObhe7dC1v2fmZiAC6Ds3WHR11IfqoUgCkIwJ590Ej+ElygJFF XxI82wtEz9hkeLLvItpyEJNVjppViRW+Dgl/U7ypHB3qDgYjgwARAQABzSBHZW9yZ2UgTWl0 Y2hlbGwgPGdlb3JnZUBtNXAuY29tPsLBlwQTAQgAQQIbIwUJCWYBgAULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBDXTOGR5LbCVuZCmV8EREt5vqeH5BQJYWXFRAhkBAAoJEMEREt5vqeH5 SRsQAIb/crcxXyAyeokAuTjN+YXkEFdVv/JrOgNXKdCukXt/UGd3nZTcAzpllytDIvIlPTNI 2/nZ5sm6ymeyVwmvkrM/r3sRUib5ftakJpbv0wn2j+eCGAca8IA2frBUg9bEXKcHRJRQCztG cpousHzOziTCRQ/1NfPcIFBNbQMPUVoQ96cJPvM/XfFGOISKKsSI78skHm6Oazh1hLCQTKvy hNNgVpNP/PHCHMbla1+SNgyn35CUelTh153lnkOhw1XyX6IxY4o5Bhcf3YrxAVcoeHq3FEH0 T3ygAdI14VrZGXXitBAMI78QLB0FiWMoPQ3Oddnoh6tlT4djnsc9IW0Tzk6ozvQL7sKdYgO8 ZlIpkBqQQfpSHzwPu9EkOFggPWB9WtP3IajQ0lt1LovqMug4C8APRC2/1cvi+GUIRwjVsop0 ukhlLTTJd3/S4Muh3s87M4Rdek1xpOiMKjYOVaxmhQQ91oz971zJuJJWpX7uUQiXx9oEwCDW TvI5yEuqYLsMUwx3d2iFTr+HbtlBJmF+Vguyrn/a3vFK8P/TH9fMvNeTdln9SuOOa1SAMMcy czOpBYg9RpzNLshUJVrhKzugT59Rl2wsNQsQCUkzgF3f8cZHJyl+8x6t0nuM9LTkMv13YIXS Mde3UOD2EaBhmeIqvC/adQHxpNudvxM1viFJDnTnzsFNBFgnLnwBEAC7kzsZqjBRPonnr/63 C98FSa3LikvqQWygmPSCC9DsFX/fB0CSXIHTrHQ4a7lXdfZyTZcGdxXN+MC8O8thjvVq6WYm CpyOJ/bq4SxOa9cnQSJ5SP9VCmVoDN/3T4ybXFzLAt756kfQ5jsVuP0m6iQ4z918zhZXk+Mo qdwGjYTxsBD02a7m1aeYafyaI2mZ+vdEy0cDhV4PDXI6ThLNAavTPji6ZrBdH5a4LMg30u8v kkNe0eCKvU+0cWb2VQIeddMhhiGSBE2Dv+A4eNe1VZvoGpLDlYdnoHraVFL2GHNFGymj/uRf 1hja5kW9Rekisqby5SpGABwrFFEs7ABpfYG0IRBKbjjG1Cqdfe/R6ETJFvvNOOpCKPAWeqYf Isxv4OHWTmhKihhIanYWCAe1MDLRRbj7UrOTZeia2WJ4v58xbU5rVQoHI/Tzaq86rXzRWITc 5w+kresMad0zpvQ900BdHc8ATNY2aW/Fr5it5OqMvIW6Y4gc8Z95MkQPVc8vj3WzfxuWtZNK 6Wbv4r6Qbiwg1RpY1JoEIoF4OsZJOVMQaB6ezD7xvaa2eY6nRGtq9SoJxo2qvlSbLlKq8NdH VYHhtTbpQ1NfrEJfv5sLX5W5IpoYww48bFYH67+7r1f/W3voBptSgE7qnYAm6Em9bEAKOQEX 8BXwoa54fn03z6TyhwARAQABwsFkBBgBCAAPBQJYJy58AhsMBQkJZgGAAAoJEMEREt5vqeH5 6PcP+JvrMM7ZM8UlnbrY4Er9psPj3ayllRhQFA9h6GNUKYuSzSxOrPaT96s8KUGMCr4jrn1S WFmeeNLLOgSJmQRicMh6LmnKq6WY6UaOfn7Y9O62NUjXfEI3Bw4ID36YCdQ+CJd14r0YOf4M 5F50bvHV3lbzD9TXZPxecHKC2ZUMBbT37tsckWCLL3lzKMsqQLwBUmgBl1NIUc7gyXxiNyxb 6SPVF1NguDDM438mcg9jSRAyjgAk6POUEM8YIXkw0Gg6HF1tNMJJ1xTMBCLYl6fHTtsxJpf9 yo+Hnw346hqYzXn4ytHJ49Ngcre8uhqM1l8iMpa17tEjfalkc1FWR9/qvoowOKtxpvblsy3a YzeEFgIomhLzISz6IafQ3S7Mt5AFlqwN/qQHx0k2V66GzDG0ngZBPROP1sXSpdJzO0zbJQFn MZE3f+y8vXMcE/MBXR7kAdYYApiEMQzVxy9TdQDU3lGLptcPZ1IOntTNFFrvp5NwsKi+6C9i mXtd5kJ1PwhcJYW3/ov/490l60C5SFUL/RZ/NOW8SHFaPcqlGcqIlexFKbzrMQwmYXo95jWB eZ0Qn+raxCUFZNGiwtusyQGBMcpHVJUanOCNd1z4ZbfmhUjDJKC/7YWDunvaDRSukGiRCl6J s8caqXHiVZjx+s76iWzm6AHRP5jg9D6EtTOrGiE= Message-ID: <97091fe4-0f4b-c3fb-00e9-065c4d92468a@m5p.com> Date: Wed, 4 Jul 2018 21:42:31 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <201807050107.w6517hug056380@slippy.cwsent.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JIamB7Wbang2RcMOqSXiHexe7iRnhQWDU" X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [10.100.0.247]); Wed, 04 Jul 2018 21:42:33 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 01:42:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JIamB7Wbang2RcMOqSXiHexe7iRnhQWDU Content-Type: multipart/mixed; boundary="7twFZbbfUqIbHzYidqqWsPn86VnqEhh1C"; protected-headers="v1" From: George Mitchell To: freebsd-hackers@freebsd.org Message-ID: <97091fe4-0f4b-c3fb-00e9-065c4d92468a@m5p.com> Subject: Re: Confusing smartd messages References: <201807050107.w6517hug056380@slippy.cwsent.com> In-Reply-To: <201807050107.w6517hug056380@slippy.cwsent.com> --7twFZbbfUqIbHzYidqqWsPn86VnqEhh1C Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/04/18 21:07, Cy Schubert wrote: > [...] > Failing that dd_rescue the whole device. Make sure your zpool has been > exported. If "repairing" a UFS root filesystem, use single user mode or= > the machine will panic, though no loss of data, just a PITA. > [...] I've never heard of dd_rescue, but I see it is in sysutils/dd_rescue. I'll try that when the long smartctl test finishes (i.e. tomorrow morning, most likely). Thanks for all the help! I'm pretty calm about the situation at the moment, because the zpool is not my root file system and (as of now) zraid has never failed me. Also, I can take this machine off line as required with only minor inconvenience to anyone. -- George --7twFZbbfUqIbHzYidqqWsPn86VnqEhh1C-- --JIamB7Wbang2RcMOqSXiHexe7iRnhQWDU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAls9d4cACgkQwRES3m+p 4flu1BAAiDfuMUotmpihyt+IUu5Ixw4Gu43NRodO8Y6qUykcKA8waH5e26Pt4EC5 NVwO2D9RIWDcfYTwYr0BzVpkpvPTuriKhcop8nqabMMTILo5uDM2y0H1srE7uVdk p9i7AkQMxO9C5yh1R/IGe0Ng7ctlY3+7slDiU0HLx9ZMXurvW4u3m8zpzFNyxDri k9rYwdVy8pVUnCU97EParYXvnNAcxfuyDzrIZa2F8RGYYSkHsb4RH1kFNrfYRF6n nJw9IbsCQOkSZ3dKwMFTPdxVi8X/FB4XcB1YOzTEGkV9AlbB5UcgI6M8oPiWkFUm 4xfsj1R8/9PkX+Fz4Aw6D868pkJu+1H56bXEKafr2PLhqdRyB9S1P0s72qwb67FZ J4p//ZA74y3Ki1yqAxSPEu8PkDJoXx8zRRO/bVHYlBVDD37Zl9EPZkL2wwsGDfzp GU3bCvCQdTnIKMjJV10ZMvZ+ijY2Fb4YGgLPoY9HrMteNRETv7hypBUqele+0G3Q oLEfUSz0xh3ExdDoW+yMzPWxHLzy9VLuD14oXXu7+jMJUkmVyI8ijvUk93B4uHkL 9cin0ZqGYectG/ukiKPNotyR7PhnofFcgIrwXh5Dl2tWfMd4hCMRL+gqpbvcraaf 3KTU146oJXwyhFfE5++ICJ+s4uvVHE1EJDwaIQBEg30pWdTpfdM= =WYxd -----END PGP SIGNATURE----- --JIamB7Wbang2RcMOqSXiHexe7iRnhQWDU-- From owner-freebsd-hackers@freebsd.org Thu Jul 5 04:25:53 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 322D31043B54 for ; Thu, 5 Jul 2018 04:25:53 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8905B8602E for ; Thu, 5 Jul 2018 04:25:52 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w654PnZ5046203; Wed, 4 Jul 2018 21:25:49 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w654PlLu046202; Wed, 4 Jul 2018 21:25:47 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807050425.w654PlLu046202@pdx.rh.CN85.dnsmgr.net> Subject: Re: Confusing smartd messages In-Reply-To: <5B3D70C8.60301@grosbein.net> To: Eugene Grosbein Date: Wed, 4 Jul 2018 21:25:47 -0700 (PDT) CC: George Mitchell , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 04:25:53 -0000 [ Charset windows-1252 unsupported, converting... ] > 05.07.2018 8:05, Rodney W. Grimes wrote: > > > It would of also been nice if the ata standard would of made a way > > to get the LBA of pending sectors so that a very quick rewrite attempt > > could be done to fix them. IIRC this info is avalible, but in a vendor > > specific way. > > "smartctl -t long" reveals LBA of first pending sector. That is vendor dependent and well only return the pending sector if the pending sector fails for most vendors. It may fix the sector if it could read it. This is also a full surface read, so not a direct path to get the LBA's that are in the pending list. The software that comes with a PC3000 can get this list from most drives, but it knows a lot of vendor specific, and often even undocumented commands. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Jul 5 04:29:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA3E71043F5B for ; Thu, 5 Jul 2018 04:29:29 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D1EB861C7 for ; Thu, 5 Jul 2018 04:29:29 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w654TRl6046216; Wed, 4 Jul 2018 21:29:27 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w654TRrB046215; Wed, 4 Jul 2018 21:29:27 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807050429.w654TRrB046215@pdx.rh.CN85.dnsmgr.net> Subject: Re: Confusing smartd messages In-Reply-To: <53c3dd92-d408-8d05-9746-d6b0a5a32b5b@m5p.com> To: George Mitchell Date: Wed, 4 Jul 2018 21:29:27 -0700 (PDT) CC: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 04:29:29 -0000 > On 07/04/18 21:13, Eugene Grosbein wrote: > > 05.07.2018 8:05, Rodney W. Grimes wrote: > > > >> It would of also been nice if the ata standard would of made a way > >> to get the LBA of pending sectors so that a very quick rewrite attempt > >> could be done to fix them. IIRC this info is avalible, but in a vendor > >> specific way. > > > > "smartctl -t long" reveals LBA of first pending sector. > > [...] > > "zpool scrub" completed with no apparent problem, and I've just started > "smartctl -t long", which claims it will finish in 398 minutes. Is there any addition error log entries in either smartctl -a smartctl -x -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Jul 5 06:34:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D04E410295C6 for ; Thu, 5 Jul 2018 06:34:09 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A3F28B312 for ; Thu, 5 Jul 2018 06:34:08 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id w656XvTe031128 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 5 Jul 2018 16:34:03 +1000 (AEST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id w656Xq84077237 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Jul 2018 16:33:52 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id w656Xq5u077236; Thu, 5 Jul 2018 16:33:52 +1000 (AEST) (envelope-from peter) Date: Thu, 5 Jul 2018 16:33:52 +1000 From: Peter Jeremy To: "Rodney W. Grimes" Cc: Eugene Grosbein , FreeBSD Hackers , George Mitchell Subject: Re: Confusing smartd messages Message-ID: <20180705063352.GA76985@server.rulingia.com> References: <5B3D6975.2060508@grosbein.net> <201807050105.w6515uRD045567@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <201807050105.w6515uRD045567@pdx.rh.CN85.dnsmgr.net> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 06:34:10 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2018-Jul-04 18:05:56 -0700, "Rodney W. Grimes" wrote: >It would be really nice if we had a way to tell ZFS to >do the equivelent of: > dd if=3D/dev/ada1 of=3D/dev/ada1 bs=3D128k conv=3Dnoerror,sync >in some type of lowlevel scrub operation, with proper locking >which could easily repair most of these Pending Sector errors, Agreed. >It would of also been nice if the ata standard would of made a way >to get the LBA of pending sectors so that a very quick rewrite attempt >could be done to fix them. IIRC this info is avalible, but in a vendor >specific way. As a workaround,=20 dd if=3D/dev/ada1 of=3D/dev/null bs=3D128k conv=3Dnoerro will report any errors. You can then write zeroes or garbage to those sectors (optionally followed by a scrub if you overwrote more than the faulty sectors) --=20 Peter Jeremy --AhhlLboLdkugWU4S Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAls9u9BfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzQbsA/9FifYQ2JV3Z1zHytFLjdDvc3w5scXtUR8aCbKIU4t//iWZO1aqhFSyr2/ W2POZz+WVILYMDn6gtNoQV3bm4HIGawcUe4tlQjiCGSfRkM12Sn5nvm2rR8myM4V u2lQNjjuHPA54jAy2ouKpiAn+IHilgof7KIJJNG+//CLZPxACySDx1Ve8Dch4pSs gu8Th3SeGBjQg5WahWhQ7n3BqfFFyPGqpm11yZHv0vt9kM5DwH8WrkjUvDAZyxxW WegwYXYK1HhEs+p3mHjUW2ELE8C4DrNx3eYNsnYHbucnXUbHVyK7zGbdVdERWpqS adkdhNB0qBHGpW7SMrgh1Q9woSeADJdvPFiLR4+ZjOJfsvhuL4XVdsc4tJjmHRKn mFnqCVGQE9StoHGk38UJtTlGJa1Ejv9CfWfGGO9imvnU0Omb4Wgm8gNZ9jXaZrSO K/FmxlQMNRolfyZFfFmHQS1XlMcV0DEh4U0uJAUEdEq5sVzYT7+ooRab97GNhB9i KvCSL8dMmekRA5HuOq8of4jQQWSHWZgEDWXuNZxolzdy5QU0Qb4E7LtiC0zpl78C FjOsXLAbcoLyHe0T6RiyRqEqtftdyc8yXM9rDJVJgN43vudz8kQAlTz9t+wZ2aPJ C1uKOgP41U8Rkfl2hjwP542uOdUR6A8LKubR6vUzZEb7Vc3HhWs= =/V3W -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-hackers@freebsd.org Thu Jul 5 08:18:21 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B0F91032BA4 for ; Thu, 5 Jul 2018 08:18:21 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (unknown [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 174CD8F087 for ; Thu, 5 Jul 2018 08:18:20 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w658IDUc015684 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Jul 2018 10:18:14 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-rwg@pdx.rh.CN85.dnsmgr.net Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w658I9ek082936 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2018 15:18:09 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Confusing smartd messages To: "Rodney W. Grimes" References: <201807050425.w654PlLu046202@pdx.rh.CN85.dnsmgr.net> Cc: George Mitchell , FreeBSD Hackers From: Eugene Grosbein Message-ID: <5B3DD43B.5010208@grosbein.net> Date: Thu, 5 Jul 2018 15:18:03 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201807050425.w654PlLu046202@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 08:18:21 -0000 05.07.2018 11:25, Rodney W. Grimes wrote: >>> It would of also been nice if the ata standard would of made a way >>> to get the LBA of pending sectors so that a very quick rewrite attempt >>> could be done to fix them. IIRC this info is avalible, but in a vendor >>> specific way. >> >> "smartctl -t long" reveals LBA of first pending sector. > > That is vendor dependent Have not seen any exceptions with modern (e.g. last 5 years) HDDs. > and well only return the pending sector > if the pending sector fails for most vendors. It may fix the > sector if it could read it. This is first time I hear about fixind sector problem by just reading it. I believed that only a write can fix it. From owner-freebsd-hackers@freebsd.org Thu Jul 5 10:52:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 553CD104077F for ; Thu, 5 Jul 2018 10:52:29 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) by mx1.freebsd.org (Postfix) with ESMTP id CFDFF75647 for ; Thu, 5 Jul 2018 10:52:28 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id B0316A8D; Thu, 5 Jul 2018 13:52:21 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: Confusing smartd messages To: George Mitchell , FreeBSD Hackers References: From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> Date: Thu, 5 Jul 2018 13:52:21 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 10:52:29 -0000 On 05.07.2018 3:03, George Mitchell wrote: > which sounds like it confirms the log message above. The disk is > part of a zraid pool whose "zpool status" also says everything is > okay. What's the recommended action at this point? -- George In my experience it is begin of disk death, even if overall status is PASSED. It could work for month or may be half a year after first Offline_Uncorrectable is detected (it depends on load), but you best bet to replace it ASAP and throw away. -- // Lev Serebryakov From owner-freebsd-hackers@freebsd.org Thu Jul 5 14:53:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EAD971030421 for ; Thu, 5 Jul 2018 14:53:25 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E0C180B3E; Thu, 5 Jul 2018 14:53:25 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w65EibbK017386 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Jul 2018 16:44:37 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w65EiWew017383; Thu, 5 Jul 2018 16:44:32 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Thu, 5 Jul 2018 16:44:32 +0200 (CEST) From: Wojciech Puchar To: Lev Serebryakov cc: George Mitchell , FreeBSD Hackers Subject: Re: Confusing smartd messages In-Reply-To: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> Message-ID: References: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 14:53:26 -0000 >> okay. What's the recommended action at this point? -- George > > In my experience it is begin of disk death, even if overall status is > PASSED. It could work for month or may be half a year after first > Offline_Uncorrectable is detected (it depends on load), but you best bet > to replace it ASAP and throw away. well my disk had this and live happily for 3 years. It JUST means that some sectors are unreadable which may be a reason that at some some write got wrong because of hardware problem. But this problem may be - and possibly were - powerdown while writing, or power spike. the media itself could be fine. the best action in such case is to force rewrite whole drive with some data. with gmirror it is as easy as first checking second drive for no errors, then forcing remirror. From owner-freebsd-hackers@freebsd.org Thu Jul 5 16:11:36 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B0F41038698 for ; Thu, 5 Jul 2018 16:11:36 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E08D84EAF; Thu, 5 Jul 2018 16:11:35 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-oi0-x22a.google.com with SMTP id d189-v6so17911224oib.6; Thu, 05 Jul 2018 09:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WZ2wsYhtVL1hUyIJVsXmwuAuAxJzsn7T6bie5dJ4sik=; b=DRx7sWqByay0DqmEkR2CtFBxvIY/gWiQ8HmeElTNz9ZyxhT9de+NC5+CmPaM7FCz2n kISBp2LGR2KOnZMpF7EPOIOMhSFlvPfDsfptrj11gUqlb9Yq1LOOMY3mBHNf8reg/huA Q9w4wFPFkn6+X9Dof3rDytUmApX5AjE0kUD9Hr1jD7DN3k9rM7oB4bASub7Cl0lbqRla njgIev3z5w57jeXZ+xw5gLHo/CHUl6LS4jNnTUtqBTDtnlNre3WKaMinV0gnzjrLu9zz M92ac3HR2kbl4M/lTVW2tFc6Z4xwPWJDPj9H/vp9ITPUGH7Eh8EJlkU1/71uIP6KwMb2 VkiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WZ2wsYhtVL1hUyIJVsXmwuAuAxJzsn7T6bie5dJ4sik=; b=Qs5d1yPf640BmUsj/K/MMB/tJX8lRQsnH3YmH0DPX46W3U8YqXXiybN1e/XpViGRjB h7nVY1aGcim+V9PXJ2pN5u8J1XJmHy9YTo2TeWIKmPgj5Y9uNAmSz7Wi2y3cXOVJoAgh W6NqRLq96mNrH3WpnhngRKKoBA/QOR9mgUlgQnNTeDMMzp9ZqgcHo9n1fWD/Akupq3mV AhVBkO25HAh6f7wPBZVjFmsDDP+uexeL+YE9Dc2poag443/E1hM4yq/dsDEx2hxa2CZj UvIIb6O5phdoz7Y5BBtJY7TY21wJPYttE88RI2EqAa+/+Gsc28d/JqFyvEQpqv3wynnO 0s+A== X-Gm-Message-State: APt69E1wuuvj5DAWO+jPk+Tm0vkVDP3P/1ZWcK/TEhcyKCydApL8NkLH UDKQGxDVzCQmVuGaFKE2F/RDkKl5v/vNUTDH34Q9aw== X-Google-Smtp-Source: AAOMgpfvl7eO+l/yCJgIig1N8LjIfDwqan9C4bf3Fa5Jg24wOFIh2AGx437Z+DighkVlj6/56bawJx/D72sQJmqTqGo= X-Received: by 2002:aca:3d43:: with SMTP id k64-v6mr6988533oia.166.1530807094956; Thu, 05 Jul 2018 09:11:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:2b9c:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 09:11:34 -0700 (PDT) In-Reply-To: References: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> From: Stefan Blachmann Date: Thu, 5 Jul 2018 18:11:34 +0200 Message-ID: Subject: Re: Confusing smartd messages To: Wojciech Puchar Cc: Lev Serebryakov , FreeBSD Hackers , George Mitchell Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 16:11:36 -0000 Another problem issue is that flash memories also exhibit the charge drain problem. They cannot be read indefinitely without occasional rewrite, as every read drains a minuscule amount of the charge. I often wished I knew of some OS/driver function/mechanism which can rewrite respective refresh media on a mounted+running system and could be, for example, run via cron. Such would not only be very useful to fix pending sectors without stopping a running machine, but also for keeping embedded machines' flash memories reliably charged over the years. On 7/5/18, Wojciech Puchar wrote: >>> okay. What's the recommended action at this point? -- George >> >> In my experience it is begin of disk death, even if overall status is >> PASSED. It could work for month or may be half a year after first >> Offline_Uncorrectable is detected (it depends on load), but you best bet >> to replace it ASAP and throw away. > well my disk had this and live happily for 3 years. > > It JUST means that some sectors are unreadable which may be a reason that > at some some write got wrong because of hardware problem. But this problem > may be - and possibly were - powerdown while writing, or power spike. > > the media itself could be fine. the best action in such case is to force > rewrite whole drive with some data. > > with gmirror it is as easy as first checking second drive for no errors, > then forcing remirror. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu Jul 5 16:39:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8683B103BAA7 for ; Thu, 5 Jul 2018 16:39:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CACFC8737D; Thu, 5 Jul 2018 16:39:48 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-x229.google.com with SMTP id 1-v6so7123847ljv.9; Thu, 05 Jul 2018 09:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uNF0ZV1vdtGn8VZs/c5Xp/ShdrKC5/kJoWnZ9H3capY=; b=ZManTTdUP1XtRKc5Zxik400QcV5DOml+7RY1TZMNjZTFwWbS0oDf1xns/TPCb5aKKV Auu9BN55zYwghwzcupCuOhbHA9yiuusPo5GBpNbQNpYLD2umk9sSLlghag72oMn0sGmk JkHY7NXm3KUntAxB35WYfDm8kHHrdwAUfd/xSAGxnghQU+8VX4F6EfXnw57KFEUvb+6+ SrhahWb8XaY/HPRZwZo81F4M4xVhCMaSuKBx7QEP7qFJREk7U9zh641McQ2GWtIvvTo8 Gv7NG6+rMy9jKlRQ6m+Yubf2TkJq5i/4BlahgGtPDFlo2ZRq7KztxS1NujAySzhAY8o6 Tl4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uNF0ZV1vdtGn8VZs/c5Xp/ShdrKC5/kJoWnZ9H3capY=; b=VJHBSQOWMTrMk5AUKziVaAwmdYwv0gFRzi+vrWtwHf1H33Us8V34Q6dwtV1RiNGdtr gpzSWcc9TZw1oYRQzGU0MdQACdvb10BETrV+/mwEg65qW/ZkOIuxx1N09nZ9DUjNXDD3 QHKFAqG+Uic9PmltR7S70cqJAlVRSnfgKVkC+f/krtCMhSqLJPc0StuD4X4Ym13d9qEJ GPytMUZyvb7NoN2HMGotuBzW08BG1MYRlFQRt4JaD0rV7SvSFIX6YPVmZN3tbr1plZnG 0qEYNw34m4KZmDQCdgb63kHj7cS6C7TOrFIN7G/lA8BkL3SsRh1WZizL3X74KS1YHak3 j0Aw== X-Gm-Message-State: APt69E1PSXbjUPQgEBLh5tEKth3qiWpqnOYtVSw3UhvzjIVGaZpGKROi UIgJAwJBJT3bcXvRUIfYAWCaSXYA0mSoW9pZ44w= X-Google-Smtp-Source: AAOMgpcaRps6XYQIKOhbAxZfyJoZ2CvJ+z4PEY5MVsg1OZ7H1HpnemeyC/N5+yvEhAUQ1TUBZKQ60van7p9GsXvl+Zo= X-Received: by 2002:a2e:3101:: with SMTP id x1-v6mr4628752ljx.8.1530808786267; Thu, 05 Jul 2018 09:39:46 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 2002:ab3:1b91:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 09:39:45 -0700 (PDT) In-Reply-To: References: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> From: Alan Somers Date: Thu, 5 Jul 2018 10:39:45 -0600 X-Google-Sender-Auth: 3mAMel_QA4gxlLQ0g7svzEkKZkc Message-ID: Subject: Re: Confusing smartd messages To: Stefan Blachmann Cc: Wojciech Puchar , FreeBSD Hackers , George Mitchell , Lev Serebryakov Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 16:39:49 -0000 My advice to the OP is to chill out. SMART is inconsistently implemented by different drive vendors and it's very hard to interpret its output. I would only recommend replacing a drive based on its SMART status for two reasons: 1) The drive is under warranty and the vendor agrees to a free replacement based on the SMART output alone. The vendors know the meaning of their own SMART fields better than you do. 2) A large statistical dataset shows that this particular SMART field is correlated with early failure, for your model of hard drive (or at least a similar model). Backblaze maintains one such dataset, which they periodically publish on their blog. There are a few other outdated datasets in the academic literature. One from AOL, and several from supercomputer operators. But Backblaze's is the best because a) it's current, b) it's large, and b) they have a very diverse set of hard drives. Still, even Backblaze can sound a little superstitious (they replace an entire chassis once several of its drives have had SMART problems). https://www.backblaze.com/blog/hard-drive-reliability-q1-2015/ If the drive is not RMAable and you're nervous because you love your data, then you might consider setting up a hotspare. zfsd(8) will activate it the moment that one of your current drives fails. You can even configure the hotspare to be spun down most of the time so it won't be affected by the mechanical shocks or regular wear that the live drives endure. Rewriting suspicious sectors is useless in this day and age. HDDs and SSDs already do it internally and have for years. Even healthy sectors get rewritten every now and then due to the adjacent track interference problem. About the only kind of problem that could develop on the track that the HDD/SSD won't fix itself would be a checksum error. Those are very rare, and ZFS will fix them immediately. -Alan "too well versed in hard drive reliability for my own good" Somers On Thu, Jul 5, 2018 at 10:11 AM, Stefan Blachmann wrote: > Another problem issue is that flash memories also exhibit the charge > drain problem. > They cannot be read indefinitely without occasional rewrite, as every > read drains a minuscule amount of the charge. > > I often wished I knew of some OS/driver function/mechanism which can > rewrite respective refresh media on a mounted+running system and could > be, for example, run via cron. > > Such would not only be very useful to fix pending sectors without > stopping a running machine, but also for keeping embedded machines' > flash memories reliably charged over the years. > > > > On 7/5/18, Wojciech Puchar wrote: > >>> okay. What's the recommended action at this point? -- George > >> > >> In my experience it is begin of disk death, even if overall status is > >> PASSED. It could work for month or may be half a year after first > >> Offline_Uncorrectable is detected (it depends on load), but you best bet > >> to replace it ASAP and throw away. > > well my disk had this and live happily for 3 years. > > > > It JUST means that some sectors are unreadable which may be a reason that > > at some some write got wrong because of hardware problem. But this > problem > > may be - and possibly were - powerdown while writing, or power spike. > > > > the media itself could be fine. the best action in such case is to force > > rewrite whole drive with some data. > > > > with gmirror it is as easy as first checking second drive for no errors, > > then forcing remirror. > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@ > freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu Jul 5 17:03:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84637103DE9D for ; Thu, 5 Jul 2018 17:03:38 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: from puchar.net (puchar.net [194.1.144.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 023B789727; Thu, 5 Jul 2018 17:03:37 +0000 (UTC) (envelope-from wojtek@puchar.net) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.15.2/8.15.2) with ESMTPS id w65H3Zii035027 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Jul 2018 19:03:35 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Received: from localhost (puchar-wojtek@localhost) by puchar.net (8.15.2/8.15.2/Submit) with ESMTP id w65H3UUt035024; Thu, 5 Jul 2018 19:03:30 +0200 (CEST) (envelope-from puchar-wojtek@puchar.net) Date: Thu, 5 Jul 2018 19:03:30 +0200 (CEST) From: Wojciech Puchar To: Alan Somers cc: Stefan Blachmann , FreeBSD Hackers , George Mitchell , Lev Serebryakov , Wojciech Puchar Subject: Re: Confusing smartd messages In-Reply-To: Message-ID: References: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 17:03:38 -0000 > > Rewriting suspicious sectors is useless in this day and age. HDDs and SSDs > already do it internally and have for years. Even healthy sectors get unreadable sectors cannot be rewritten by drive electronics as it doesn't know what to rewrite. it may possibly remap it but still report read error until some data will be written - unless giving no error and returning meaningless data is an accepted behaviour. only on write it can be done properly. > that the HDD/SSD won't fix itself would be a checksum error. Those are yes and this will happen if you powerdown your disk on write. or get some power spike or other source of noise that would affect electronic components. performing full disk rewrite (so not zfs rebuilds) and THEN looking at smart stats and THEN performing regular smartctl -t long will tell the truth. which usually is "drive is fine" in my practice. really faulty drive will QUICKLY develop new problems. From owner-freebsd-hackers@freebsd.org Thu Jul 5 17:09:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03133103E75A for ; Thu, 5 Jul 2018 17:09:28 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 53F3589D3D for ; Thu, 5 Jul 2018 17:09:28 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w65H9IAA048598; Thu, 5 Jul 2018 10:09:19 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w65H9IfA048597; Thu, 5 Jul 2018 10:09:18 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807051709.w65H9IfA048597@pdx.rh.CN85.dnsmgr.net> Subject: Re: Confusing smartd messages In-Reply-To: <20180705063352.GA76985@server.rulingia.com> To: Peter Jeremy Date: Thu, 5 Jul 2018 10:09:18 -0700 (PDT) CC: Eugene Grosbein , FreeBSD Hackers , George Mitchell X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 17:09:29 -0000 > On 2018-Jul-04 18:05:56 -0700, "Rodney W. Grimes" wrote: > >It would be really nice if we had a way to tell ZFS to > >do the equivelent of: > > dd if=/dev/ada1 of=/dev/ada1 bs=128k conv=noerror,sync > >in some type of lowlevel scrub operation, with proper locking > >which could easily repair most of these Pending Sector errors, > > Agreed. > > >It would of also been nice if the ata standard would of made a way > >to get the LBA of pending sectors so that a very quick rewrite attempt > >could be done to fix them. IIRC this info is avalible, but in a vendor > >specific way. > > As a workaround, > dd if=/dev/ada1 of=/dev/null bs=128k conv=noerro > will report any errors. You can then write zeroes or garbage to those > sectors (optionally followed by a scrub if you overwrote more than the > faulty sectors) Though this is a good test to run be-aware that this only report errors if infact the read fails, and often pending sectors do not fail as they are a transient error. This is also a very long and slow test, I can go to a PC3000 driver recovery based system and have the pending sector list in a mater of a single command and less than 1s of time. I can also some times obtain that info by hooking up a TTL serial cable to the jumpers on the drive and issuing commands to the controller chip. But again, this is a very vendor specific situation and rather intrusive to do. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Jul 5 17:23:04 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2536103FBC1 for ; Thu, 5 Jul 2018 17:23:04 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2B318AD73; Thu, 5 Jul 2018 17:23:03 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-x22f.google.com with SMTP id 1-v6so7214186ljv.9; Thu, 05 Jul 2018 10:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MseNDIcBnGoqbNkTrH/Tdo5NYgyx6iKJ1xFzY5hoftU=; b=dUPQB35Jn811+FpqBem18KYqKnu1ShYfzELELM5KV6NQcDWizseu6M5gy26uffX41a NJYuaM+ymhinOB/XVc/c4/sRTkrYblh+UyKnvxswMxBLRQr5Rv+Yawuj1EAnhgs3Z4rY SdMwXqVETTmej71t7tiMg2WgDe0TWm5Ds/ohrwB6UdphJE2KaYojyYeG/s0yg+GBLEi8 BkHRoNGQwunJp/G4GpR5quxyUFlm3kirrpiohiThlfzG/vvpaqw6qW2MiFEDwJIMG4WS QTMhxx4DzHr2gMEdmh2bgH0Zztb/+NLUSNL4KAIyEHhicBhu8lFGG5xCiKVVRdhwslcC l9/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MseNDIcBnGoqbNkTrH/Tdo5NYgyx6iKJ1xFzY5hoftU=; b=O2cxnKhKDA0AaP8y73vdT6DKf5W9JjdWPBVOd6F1hkAsMLUYDFeGLxBSDgpJOXJOD8 LAqNSyeB3QXjU9D0qy9Ti3aTZTsbZEehy2e8yMd468rQvi7uZTur711Se0wzfDK/3syY BFPUdMd21FNyM86xv9HW6p0N2ai1r0fKlWLxLr05XSk/g50A14lnM9iY8830yyfBWN64 PtxBy91b8bIdEdbcfCELJnqXtZPh+X2DYVfCyhWXwzERETq3JC261PCjn6mEa87v+x+Q SXXTGuSlfvbVkA6j9VgIqKFGFHMWbDRbmGaLKRRo9vrp8HYUk1g0uuuA98z5kwUB8vce olHA== X-Gm-Message-State: APt69E1Y8VmDjkz1zJQWAfV9AV8UvNRs8AHzJvijq0eEtP3JUAS0AOOG 8+rwDmt3TQHYcZx1/ymyR3pRJ+H4Vrbu3tyBqYU= X-Google-Smtp-Source: AAOMgpenpE1Q8lwm8arweE4ELlOK5ZT7YCgng58QL2lBPxAVY1EdN8B2XUxewm5mYbLRB1w4tRp6WgHBJZYCPJJ2ncE= X-Received: by 2002:a2e:534e:: with SMTP id t14-v6mr4476629ljd.73.1530811382353; Thu, 05 Jul 2018 10:23:02 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 2002:ab3:1b91:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 10:23:01 -0700 (PDT) In-Reply-To: References: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> From: Alan Somers Date: Thu, 5 Jul 2018 11:23:01 -0600 X-Google-Sender-Auth: JY0WxT17E-6SkZOFrGKeQug1EiM Message-ID: Subject: Re: Confusing smartd messages To: Wojciech Puchar Cc: Stefan Blachmann , FreeBSD Hackers , George Mitchell , Lev Serebryakov Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 17:23:05 -0000 On Thu, Jul 5, 2018 at 11:03 AM, Wojciech Puchar wrote: > >> Rewriting suspicious sectors is useless in this day and age. HDDs and >> SSDs >> already do it internally and have for years. Even healthy sectors get >> > > unreadable sectors cannot be rewritten by drive electronics as it doesn't > know what to rewrite. it may possibly remap it but still report read error > until some data will be written - unless giving no error and returning > meaningless data is an accepted behaviour. > But if that disk is already managed by ZFS, the pool is redundant, and the bad sector is allocated by ZFS, then ZFS will immediately rewrite the unreadable sector. > > only on write it can be done properly. > > that the HDD/SSD won't fix itself would be a checksum error. Those are >> > > yes and this will happen if you powerdown your disk on write. or get some > power spike or other source of noise that would affect electronic > components. > It happens surprisingly rarely. Even on a sudden power loss, the drive is usually able to finish its current write operation. When you run into problems would be if the power loss were coincident with a mechanical shock that knocks the head off-track, or something like that. > > performing full disk rewrite (so not zfs rebuilds) and THEN looking at > smart stats and THEN performing regular smartctl -t long will tell the > truth. > > which usually is "drive is fine" in my practice. really faulty drive will > QUICKLY develop new problems. > Yeah, that should make the error go away. It takes a long time, though. With a SCSI drive, you can get the exact LBAs affected with a "READ DEFECTS" command. But there isn't a vendor-independent equivalent for SATA, unfortunately. -Alan From owner-freebsd-hackers@freebsd.org Thu Jul 5 17:29:13 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E082C10406EB for ; Thu, 5 Jul 2018 17:29:13 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D28F8B65D for ; Thu, 5 Jul 2018 17:29:13 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w65HTBZ3048706; Thu, 5 Jul 2018 10:29:11 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w65HTBnn048705; Thu, 5 Jul 2018 10:29:11 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807051729.w65HTBnn048705@pdx.rh.CN85.dnsmgr.net> Subject: Re: Confusing smartd messages In-Reply-To: <5B3DD43B.5010208@grosbein.net> To: Eugene Grosbein Date: Thu, 5 Jul 2018 10:29:11 -0700 (PDT) CC: George Mitchell , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 17:29:14 -0000 [ Charset windows-1252 unsupported, converting... ] > 05.07.2018 11:25, Rodney W. Grimes wrote: > > >>> It would of also been nice if the ata standard would of made a way > >>> to get the LBA of pending sectors so that a very quick rewrite attempt > >>> could be done to fix them. IIRC this info is avalible, but in a vendor > >>> specific way. > >> > >> "smartctl -t long" reveals LBA of first pending sector. > > > > That is vendor dependent > > Have not seen any exceptions with modern (e.g. last 5 years) HDDs. > > > and well only return the pending sector > > if the pending sector fails for most vendors. It may fix the > > sector if it could read it. > > This is first time I hear about fixind sector problem by just reading it. > I believed that only a write can fix it. Most drive firmware if at any time a pending sector reads correctly the drive attempts to do a repair since it now has the data that belongs in that sector. It would be very bad firmware that did not attempt to repair a pending sector that it had just successfully read. There use to be (and probably still are) vendor specific commands to do things like head offset, head flight, etc so you could try to recover these sectors, this has all been shoved into the on HDA controller now that they have the CPU power to do all sorts of tricks in attempting to get that data back, BUT you have to tell the drive to read the sector or it makes no attempt to recover it. Some firmware if the number of raw bits in error was low enough simply remove the LBA from the pending list, as we can now read the sector. Some firmware well re-write the sector, read it back and see if it still reads good, and if so remove it from pending, if it fails the drive attempts a remap operation. A write operation with no regard to getting the data out of the LBA usually does "fix it" as the drive is smart enough to know that a write to a pending sector means one no longer cares about that data and the drive is free to do what ever it wants to repair the error. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Jul 5 17:43:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DADEE1041BC6 for ; Thu, 5 Jul 2018 17:43:57 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4983E8C1AD; Thu, 5 Jul 2018 17:43:57 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w65HhsAY048744; Thu, 5 Jul 2018 10:43:54 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w65HhsYb048743; Thu, 5 Jul 2018 10:43:54 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807051743.w65HhsYb048743@pdx.rh.CN85.dnsmgr.net> Subject: Re: Confusing smartd messages In-Reply-To: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> To: lev@freebsd.org Date: Thu, 5 Jul 2018 10:43:54 -0700 (PDT) CC: George Mitchell , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 17:43:58 -0000 > On 05.07.2018 3:03, George Mitchell wrote: > > > which sounds like it confirms the log message above. The disk is > > part of a zraid pool whose "zpool status" also says everything is > > okay. What's the recommended action at this point? -- George > > In my experience it is begin of disk death, even if overall status is > PASSED. It could work for month or may be half a year after first > Offline_Uncorrectable is detected (it depends on load), but you best bet > to replace it ASAP and throw away. The appearance of pending or offline sector issues indicating immanant death should be weighted to drive age. If the drive is young, say less than 100 to 200 hours, I would attribute this to marginal sectors at birth of drive that did not get caught during drive manufacture and just get them remapped and move on. Many drives have a special state when the hours is <100 in that all raw read errors with more than N bits in error, before ecc is applied, automatically and silently add these to the manufactures remap table. A very similiar thing is used at drive manufacture time to create the initial table, basically a "smartctl -t long" that has tweaked parameters and logging turned off. If the drive is older than this I would probably attribute only 2 to a one time event like emergency power off retract, marginal power situation, or shock or vibrtion during write and not be too concerned. If the drive grows additional pending/offline sectors I would then start to be concerned. Without any growth though these are almost always one off events caused by any of many methods. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Jul 5 17:50:45 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F9F0104249E for ; Thu, 5 Jul 2018 17:50:45 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 888698C786; Thu, 5 Jul 2018 17:50:44 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x235.google.com with SMTP id y127-v6so7645666lfc.8; Thu, 05 Jul 2018 10:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EZM6wgG2g7aROon7FC4p27kgocy9FoMYF79FKhTiSHY=; b=RQrHXSADJqAFU3CLK+bQpBY7A4E9NHgc3foQlpoUPOxSiW1tmWpIoiO+M6Ui8+WB4L IumqMk/RB4upGaT+RHK4OHnJy9CzZzmsaXhITnFYxuZl7Vyx9fw/y6NqQ5GmdSQZDuYK AYiuaazzttvQW2JkVXEDg6exj0k4QGkO3/6JTjNsNKA8sai85aCfkNk12x8UMcDA1fpQ P8peD0VkZaXWypnOGAHIzTfPhkULDymD29eISv9PoruPCrF0QGFxB9usUuAleXEq5+A8 t540Qi9gpQe8zfLC7lt47F5BFcGzWIieH+ULWkcprhvxVup9fAn3wKWKtvIpxhGWdGBT 3jFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EZM6wgG2g7aROon7FC4p27kgocy9FoMYF79FKhTiSHY=; b=hidZBx2JnkHpozHvYErH/v9MMoKRYk2PTshE7SGOBzSjOJsYwCdkoKyJTuywjpcV0L Y2QPIPafM/TTvSUmVPWHRxXLIOH/EPxpTXZI7oL+jU0tp8mc5xUZUpfj1Wr0jrxPEm1X oN3G0fUv3P+TBAftT5OO0dzIPtDY1mZDRqdbgA1q3Jv95B/RGXdkzsYS2G6lPISftaT7 rwbnSgf6PgseDxLYNcjeYJziYAm9wJkp7T00YmPCvmOOxURGJwj93jUoMlQ1uSXpkZMh 9s9MRb+6Sy5oAAVYzofryaqdd7g5H34thcz2wZ41TyOXS+0iaNWv8mH53XXtl8MiCZe8 Pb4g== X-Gm-Message-State: APt69E3JSZ7th6K5vmkZRtPhLC6gC9w570BKvRoTHmsQd1dEKsaJvAw+ cjoIpX4mWRqpLKiIvi4ZF8K0NhkAXU7o+Gi3vDQ= X-Google-Smtp-Source: AAOMgpd4X8ohztZfxdnwLdnKr+xjMXP2r+kFg82VhfXxEa9UXqIB7RpM05gRZV6EOfIstmIEorVwDE5RsqLuMIdvoUI= X-Received: by 2002:a19:a417:: with SMTP id q23-v6mr4917625lfc.59.1530813042825; Thu, 05 Jul 2018 10:50:42 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 2002:ab3:1b91:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 10:50:41 -0700 (PDT) In-Reply-To: <201807051743.w65HhsYb048743@pdx.rh.CN85.dnsmgr.net> References: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> <201807051743.w65HhsYb048743@pdx.rh.CN85.dnsmgr.net> From: Alan Somers Date: Thu, 5 Jul 2018 11:50:41 -0600 X-Google-Sender-Auth: qevRg8-uruFIJhPx2UQs9WE88NU Message-ID: Subject: Re: Confusing smartd messages To: "Rodney W. Grimes" Cc: Lev Serebryakov , FreeBSD Hackers , George Mitchell Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 17:50:45 -0000 On Thu, Jul 5, 2018 at 11:43 AM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On 05.07.2018 3:03, George Mitchell wrote: > > > > > which sounds like it confirms the log message above. The disk is > > > part of a zraid pool whose "zpool status" also says everything is > > > okay. What's the recommended action at this point? -- George > > > > In my experience it is begin of disk death, even if overall status is > > PASSED. It could work for month or may be half a year after first > > Offline_Uncorrectable is detected (it depends on load), but you best bet > > to replace it ASAP and throw away. > > The appearance of pending or offline sector issues indicating > immanant death should be weighted to drive age. If the drive > is young, say less than 100 to 200 hours, I would attribute > this to marginal sectors at birth of drive that did not get > caught during drive manufacture and just get them remapped > and move on. Many drives have a special state when the > hours is <100 in that all raw read errors with more than > N bits in error, before ecc is applied, automatically and > silently add these to the manufactures remap table. A very > similiar thing is used at drive manufacture time to create > the initial table, basically a "smartctl -t long" that has > tweaked parameters and logging turned off. > The famous Weibull distribution. I believe the Backblaze reports talk about it. > > If the drive is older than this I would probably attribute > only 2 to a one time event like emergency power off retract, > marginal power situation, or shock or vibrtion during write > and not be too concerned. > > If the drive grows additional pending/offline sectors I > would then start to be concerned. Without any growth > though these are almost always one off events caused > by any of many methods. > The OP hasn't watched 100,000 drives age. Backblaze has. That's why my advice is to replace them according to the failure indicators reported by Backblaze or the manufacturer, without reading too much into the meaning. -Alan From owner-freebsd-hackers@freebsd.org Thu Jul 5 18:01:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7FC910434FB for ; Thu, 5 Jul 2018 18:01:10 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 439E78D4F2; Thu, 5 Jul 2018 18:01:10 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w65I18nD048842; Thu, 5 Jul 2018 11:01:08 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w65I18en048841; Thu, 5 Jul 2018 11:01:08 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807051801.w65I18en048841@pdx.rh.CN85.dnsmgr.net> Subject: Re: Confusing smartd messages In-Reply-To: To: Stefan Blachmann Date: Thu, 5 Jul 2018 11:01:08 -0700 (PDT) CC: Wojciech Puchar , FreeBSD Hackers , George Mitchell , Lev Serebryakov X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 18:01:11 -0000 > Another problem issue is that flash memories also exhibit the charge > drain problem. > They cannot be read indefinitely without occasional rewrite, as every > read drains a minuscule amount of the charge. > > I often wished I knew of some OS/driver function/mechanism which can > rewrite respective refresh media on a mounted+running system and could > be, for example, run via cron. > > Such would not only be very useful to fix pending sectors without > stopping a running machine, but also for keeping embedded machines' > flash memories reliably charged over the years. It would be nice to have this feature, should not be too hard to implement just a matter of locking the device from start of read to end of write. > > On 7/5/18, Wojciech Puchar wrote: > >>> okay. What's the recommended action at this point? -- George > >> > >> In my experience it is begin of disk death, even if overall status is > >> PASSED. It could work for month or may be half a year after first > >> Offline_Uncorrectable is detected (it depends on load), but you best bet > >> to replace it ASAP and throw away. > > well my disk had this and live happily for 3 years. > > > > It JUST means that some sectors are unreadable which may be a reason that > > at some some write got wrong because of hardware problem. But this problem > > may be - and possibly were - powerdown while writing, or power spike. > > > > the media itself could be fine. the best action in such case is to force > > rewrite whole drive with some data. > > > > with gmirror it is as easy as first checking second drive for no errors, > > then forcing remirror. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Jul 5 18:15:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E16441044596 for ; Thu, 5 Jul 2018 18:15:56 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C65D8DF8D; Thu, 5 Jul 2018 18:15:55 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w65IFqSB048888; Thu, 5 Jul 2018 11:15:52 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w65IFqsB048887; Thu, 5 Jul 2018 11:15:52 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807051815.w65IFqsB048887@pdx.rh.CN85.dnsmgr.net> Subject: Re: Confusing smartd messages In-Reply-To: To: Alan Somers Date: Thu, 5 Jul 2018 11:15:52 -0700 (PDT) CC: Wojciech Puchar , FreeBSD Hackers , Stefan Blachmann , Lev Serebryakov , George Mitchell X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 18:15:57 -0000 > On Thu, Jul 5, 2018 at 11:03 AM, Wojciech Puchar wrote: > > > > >> Rewriting suspicious sectors is useless in this day and age. HDDs and > >> SSDs > >> already do it internally and have for years. Even healthy sectors get > >> > > > > unreadable sectors cannot be rewritten by drive electronics as it doesn't > > know what to rewrite. it may possibly remap it but still report read error > > until some data will be written - unless giving no error and returning > > meaningless data is an accepted behaviour. > > > > But if that disk is already managed by ZFS, the pool is redundant, and the > bad sector is allocated by ZFS, then ZFS will immediately rewrite the > unreadable sector. ZFS, if it gets a re error, will rewrite the unreadable sector to a DIFFERENT block, not over the top of the bad spot. > > only on write it can be done properly. > > > > that the HDD/SSD won't fix itself would be a checksum error. Those are > >> > > > > yes and this will happen if you powerdown your disk on write. or get some > > power spike or other source of noise that would affect electronic > > components. > > > > It happens surprisingly rarely. Even on a sudden power loss, the drive is > usually able to finish its current write operation. When you run into > problems would be if the power loss were coincident with a mechanical shock > that knocks the head off-track, or something like that. I agree that "power failure" are rare causes of write errors, and an idea of how often this might of happened is look at the emergency retract counter, if your gettng lots of those you should try to find out why and stop that. Vibration has become a serious problem though, at todays head flight hight drives are sensitive to this, you can even cause a drive to do retires by yelling at it with a loud voice :-) Look at the "high fly" counter to see if your getting this issue. > > performing full disk rewrite (so not zfs rebuilds) and THEN looking at > > smart stats and THEN performing regular smartctl -t long will tell the > > truth. > > > > which usually is "drive is fine" in my practice. really faulty drive will > > QUICKLY develop new problems. > > > > Yeah, that should make the error go away. It takes a long time, though. > With a SCSI drive, you can get the exact LBAs affected with a "READ > DEFECTS" command. But there isn't a vendor-independent equivalent for > SATA, unfortunately. My bitch exactly about ATA missing this. Though there are vendor specific commands to get it. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Thu Jul 5 18:25:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0ED11045582 for ; Thu, 5 Jul 2018 18:25:42 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 428FD8EA59 for ; Thu, 5 Jul 2018 18:25:42 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [10.100.0.31] (haymarket.m5p.com [10.100.0.31]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id w65IPHvB057835 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 5 Jul 2018 14:25:27 -0400 (EDT) (envelope-from george+freebsd@m5p.com) To: "Rodney W. Grimes" Cc: freebsd-hackers@freebsd.org References: <201807050429.w654TRrB046215@pdx.rh.CN85.dnsmgr.net> From: George Mitchell Openpgp: preference=signencrypt Autocrypt: addr=george+freebsd@m5p.com; prefer-encrypt=mutual; keydata= xsFNBFgnLnwBEADAJDiBKQX77LFRz9wZW8mz3KvaQol2nIremcws0F1mz/zgFlk6uhQVtwnL wb4XL5LdFwcNE1+QZzPLcbYWoWQlz0lBw1bMuKAgr0S6V2e0+I0DqhKeslVFctcTwtvT6pnK VLZXO/7ZGAaLzG4K5vSPzgoevU+YI/pxNsVCH2UO/c3jQW63uEt25mIZbCF1Pu4jgp4RhIgF ujn877r/j6OwBwjzRUu3E6ADp+U825d+5YCuQMEH0wIPnn9GTpXvfdKdbwOIl2akqXqs4cnk iATWfK3r6D4mvDEj1OPHlTvJYcfic7aOIiAwmx1C1v78GjXOdOOA0SGffNix3C2/8oZUO1+V Aet4MKpUKkduWSvULhIkHNZ5Nu8SIJOqge8pmtHxuNXAMfMrAjMdjPwwBFLsYg3Xa2E2oJwg ehTauwd/EDJFcVCyDCyCAYOi/BH/+XQyxzgDlY9N9qj9tHqhVPI6XK7t8UVffGiZUq4rHp5J RdOToqiTNC6eCJBczhMIW+DuFvWU9e6W708T1dz0Accn6Lrgk4eRIn3GFPBG+TxnpjAqHsbW 607dcnD3YKAqY4e+khczL4EObhe7dC1v2fmZiAC6Ds3WHR11IfqoUgCkIwJ590Ej+ElygJFF XxI82wtEz9hkeLLvItpyEJNVjppViRW+Dgl/U7ypHB3qDgYjgwARAQABzSBHZW9yZ2UgTWl0 Y2hlbGwgPGdlb3JnZUBtNXAuY29tPsLBlwQTAQgAQQIbIwUJCWYBgAULCQgHAgYVCAkKCwIE FgIDAQIeAQIXgBYhBDXTOGR5LbCVuZCmV8EREt5vqeH5BQJYWXFRAhkBAAoJEMEREt5vqeH5 SRsQAIb/crcxXyAyeokAuTjN+YXkEFdVv/JrOgNXKdCukXt/UGd3nZTcAzpllytDIvIlPTNI 2/nZ5sm6ymeyVwmvkrM/r3sRUib5ftakJpbv0wn2j+eCGAca8IA2frBUg9bEXKcHRJRQCztG cpousHzOziTCRQ/1NfPcIFBNbQMPUVoQ96cJPvM/XfFGOISKKsSI78skHm6Oazh1hLCQTKvy hNNgVpNP/PHCHMbla1+SNgyn35CUelTh153lnkOhw1XyX6IxY4o5Bhcf3YrxAVcoeHq3FEH0 T3ygAdI14VrZGXXitBAMI78QLB0FiWMoPQ3Oddnoh6tlT4djnsc9IW0Tzk6ozvQL7sKdYgO8 ZlIpkBqQQfpSHzwPu9EkOFggPWB9WtP3IajQ0lt1LovqMug4C8APRC2/1cvi+GUIRwjVsop0 ukhlLTTJd3/S4Muh3s87M4Rdek1xpOiMKjYOVaxmhQQ91oz971zJuJJWpX7uUQiXx9oEwCDW TvI5yEuqYLsMUwx3d2iFTr+HbtlBJmF+Vguyrn/a3vFK8P/TH9fMvNeTdln9SuOOa1SAMMcy czOpBYg9RpzNLshUJVrhKzugT59Rl2wsNQsQCUkzgF3f8cZHJyl+8x6t0nuM9LTkMv13YIXS Mde3UOD2EaBhmeIqvC/adQHxpNudvxM1viFJDnTnzsFNBFgnLnwBEAC7kzsZqjBRPonnr/63 C98FSa3LikvqQWygmPSCC9DsFX/fB0CSXIHTrHQ4a7lXdfZyTZcGdxXN+MC8O8thjvVq6WYm CpyOJ/bq4SxOa9cnQSJ5SP9VCmVoDN/3T4ybXFzLAt756kfQ5jsVuP0m6iQ4z918zhZXk+Mo qdwGjYTxsBD02a7m1aeYafyaI2mZ+vdEy0cDhV4PDXI6ThLNAavTPji6ZrBdH5a4LMg30u8v kkNe0eCKvU+0cWb2VQIeddMhhiGSBE2Dv+A4eNe1VZvoGpLDlYdnoHraVFL2GHNFGymj/uRf 1hja5kW9Rekisqby5SpGABwrFFEs7ABpfYG0IRBKbjjG1Cqdfe/R6ETJFvvNOOpCKPAWeqYf Isxv4OHWTmhKihhIanYWCAe1MDLRRbj7UrOTZeia2WJ4v58xbU5rVQoHI/Tzaq86rXzRWITc 5w+kresMad0zpvQ900BdHc8ATNY2aW/Fr5it5OqMvIW6Y4gc8Z95MkQPVc8vj3WzfxuWtZNK 6Wbv4r6Qbiwg1RpY1JoEIoF4OsZJOVMQaB6ezD7xvaa2eY6nRGtq9SoJxo2qvlSbLlKq8NdH VYHhtTbpQ1NfrEJfv5sLX5W5IpoYww48bFYH67+7r1f/W3voBptSgE7qnYAm6Em9bEAKOQEX 8BXwoa54fn03z6TyhwARAQABwsFkBBgBCAAPBQJYJy58AhsMBQkJZgGAAAoJEMEREt5vqeH5 6PcP+JvrMM7ZM8UlnbrY4Er9psPj3ayllRhQFA9h6GNUKYuSzSxOrPaT96s8KUGMCr4jrn1S WFmeeNLLOgSJmQRicMh6LmnKq6WY6UaOfn7Y9O62NUjXfEI3Bw4ID36YCdQ+CJd14r0YOf4M 5F50bvHV3lbzD9TXZPxecHKC2ZUMBbT37tsckWCLL3lzKMsqQLwBUmgBl1NIUc7gyXxiNyxb 6SPVF1NguDDM438mcg9jSRAyjgAk6POUEM8YIXkw0Gg6HF1tNMJJ1xTMBCLYl6fHTtsxJpf9 yo+Hnw346hqYzXn4ytHJ49Ngcre8uhqM1l8iMpa17tEjfalkc1FWR9/qvoowOKtxpvblsy3a YzeEFgIomhLzISz6IafQ3S7Mt5AFlqwN/qQHx0k2V66GzDG0ngZBPROP1sXSpdJzO0zbJQFn MZE3f+y8vXMcE/MBXR7kAdYYApiEMQzVxy9TdQDU3lGLptcPZ1IOntTNFFrvp5NwsKi+6C9i mXtd5kJ1PwhcJYW3/ov/490l60C5SFUL/RZ/NOW8SHFaPcqlGcqIlexFKbzrMQwmYXo95jWB eZ0Qn+raxCUFZNGiwtusyQGBMcpHVJUanOCNd1z4ZbfmhUjDJKC/7YWDunvaDRSukGiRCl6J s8caqXHiVZjx+s76iWzm6AHRP5jg9D6EtTOrGiE= Subject: Re: Confusing smartd messages Message-ID: <80e35157-a48e-c139-4688-3968a56a433a@m5p.com> Date: Thu, 5 Jul 2018 14:25:19 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <201807050429.w654TRrB046215@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s55drRuzMgpEMuuMTiMrbQwwrBeb3nXf9" X-Spam-Status: No, score=-1.0 required=10.0 tests=ALL_TRUSTED, RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mattapan.m5p.com X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mailhost.m5p.com [10.100.0.247]); Thu, 05 Jul 2018 14:25:28 -0400 (EDT) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 18:25:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s55drRuzMgpEMuuMTiMrbQwwrBeb3nXf9 Content-Type: multipart/mixed; boundary="9saARRh2D9fHWcqee9aPfgxJamDtKgzWl"; protected-headers="v1" From: George Mitchell To: "Rodney W. Grimes" Cc: freebsd-hackers@freebsd.org Message-ID: <80e35157-a48e-c139-4688-3968a56a433a@m5p.com> Subject: Re: Confusing smartd messages References: <201807050429.w654TRrB046215@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201807050429.w654TRrB046215@pdx.rh.CN85.dnsmgr.net> --9saARRh2D9fHWcqee9aPfgxJamDtKgzWl Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/05/18 00:29, Rodney W. Grimes wrote: >> [...] >> [me] >> "zpool scrub" completed with no apparent problem, and I've just starte= d >> "smartctl -t long", which claims it will finish in 398 minutes. >=20 > Is there any addition error log entries in either > smartctl -a > smartctl -x >=20 Actually, the smartctl -t long has not finished yet ("10% of test remaining"), so smartctl -a has no additional details yet. Stay tuned! smartctl -x says there have been 210 errors over the life of the device, which appears to be 39,311 hours. The last 24 are clearly within the last day, presumably as a result of the smartctl -t long, and they also generated a pile of log messages. I think it's time to replace the drive. Many thanks for all the helpful replies! -- George --9saARRh2D9fHWcqee9aPfgxJamDtKgzWl-- --s55drRuzMgpEMuuMTiMrbQwwrBeb3nXf9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAls+YpYACgkQwRES3m+p 4fnY1hAAoNQLcBx1u/brS33CCB81Sq258n3LJy2fmYCgEs4hBFSfg2LY6RQoEjXY GWd5znf28CfngudmnZa00ikiG7ZZxlGe6lGOVt7ZFAjP86LNJ9ewpqSem64xgoiu ro6iBxIeAMbHYTKw6R+mH10Q7kWBshnMqbBf9K93AH+sWJYPfOxoTNn5gTtH0rbX 0IK54GkfiW0ilD/Da8i54FqvAMrG1kqvdAiPQODXadITl1nw3i/HLUYTXk1yZ/AW hdoY4dNKM9YsUjb7JUdlhoPcJnimCpHiXvCpWgJE1tuvvO+25XPLiUvhC5xiFkvW Y9Apq14GA+EcbaWqjzVwMWyNL9SpkNrFaxewIawJlz3ZFRT7PS78jUImstFSwRli pbRQo348JVre3ILhvLb5BdfxUWwcWRd0bxtWPCJo0a5xDU6CONKWtFmaQJNKKcCf VqIxgxedfJXlzjkBZrbAqmRSyEov66JxoxDnl8JTbTBZYQomPb9mryLFU9czkffL EPN1l/0FQELn6ylryEWh1FtjRB2a5FERdx/WCR5rTRHxA2g17ZpeF1BnY30xtwrw 02pvse5gnhg+s/HC0051qc9+PMxoJJb513N0bmLzaFm03ONS7Xyo4jmYKkOEg9DO az/V4y039QLJnrV7X8IerG8C7pRTS4Rmjz/ZiF44pMnSmGBOtKk= =02rT -----END PGP SIGNATURE----- --s55drRuzMgpEMuuMTiMrbQwwrBeb3nXf9-- From owner-freebsd-hackers@freebsd.org Thu Jul 5 18:31:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11E571045F10 for ; Thu, 5 Jul 2018 18:31:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B4CF8F1B0 for ; Thu, 5 Jul 2018 18:31:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id t135-v6so8624415iof.7 for ; Thu, 05 Jul 2018 11:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mZCn90BQqBeyuv5yuCGb7NHoZTQMe1TAFjdY06tV2zs=; b=UrI87c7O4svNOTuwYTKw9EMjQvRheZ2U/xcOBsncGM90o1zQdSiVrPAmmKBpf/hCvW fYoGRNmLeobJXozNWdY7iWoX3znvXq6xBDO7RajtNefUiqjMDFmnqxskGHB3jDli05Kq UUyIaErOtTGviqLwO8Bch1G8Y1MDrdNhpHzcpj4aLWJ/lksxZA2NffyyHVOCcbiA7UT1 duOli4/RvxR1mdlbLs6P+91XUmUmR2mj42r7uH8EuwP/aN8aQ18sojtibunwAI7tNsUk OrpxFkPQhek0bJdIJJRKHiBCivMBsLhg8oLdErq+MrhqBuGys/YYu++346+6tkrU6bO1 F3FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mZCn90BQqBeyuv5yuCGb7NHoZTQMe1TAFjdY06tV2zs=; b=Z9UNT/bEU8wrIFkNH/YdL9pW7YWfOYwSzVqeJogyYdvL25fYDKZOIJHH3Buj/Wl7I+ SdigN7GvODjbSmHquXTmDpS//TG9Uozoegta3KRmpiohpQ2/a2BGX+0bKRyErZEyCb+K /LtIy6nXCjJ550LRFeRQyulnCl8loFYE/woVxQWO4BK8ANOjzfllnfu1TSJiBn4z/lw6 TmUtHR/nsi/tjqT8opNCQrmz7dFMqqFakULuxeELf2aAgnHmnfaeQJoXpQPJ0XjZpnck FJ310cFDekINGUxU+cLnMSs0EyQZmfICmTS+xXISr7LOAfSmvH4wLFz7TfigYPbT3dRB v/MQ== X-Gm-Message-State: APt69E1zytFx/Di2UwXw0FS7oqm71v1FrcfnaXPTRPMvNdVvXXUu1EWK MG2QDZZlYk00za39QudBoisFX1z5XFA8ufMEA41YtA== X-Google-Smtp-Source: AAOMgpckPOB9nd0tY+A861akM/bJiW3EbEJA+kRWVB4I4Gj0cJXB59rg+Qx7XUmoBeAK/ycXzdNyIVIUngzr3txaCBw= X-Received: by 2002:a6b:d40c:: with SMTP id l12-v6mr6035815iog.37.1530815491758; Thu, 05 Jul 2018 11:31:31 -0700 (PDT) MIME-Version: 1.0 References: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Thu, 5 Jul 2018 12:31:20 -0600 Message-ID: Subject: Re: Confusing smartd messages To: Stefan Blachmann Cc: Wojciech Puchar , FreeBSD Hackers , George Mitchell , Lev Serebryakov Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 18:31:33 -0000 On Thu, Jul 5, 2018, 11:13 AM Stefan Blachmann wrote: > Another problem issue is that flash memories also exhibit the charge > drain problem. > They cannot be read indefinitely without occasional rewrite, as every > read drains a minuscule amount of the charge. > It usually takes ~500k reads to hit this issue. I often wished I knew of some OS/driver function/mechanism which can > rewrite respective refresh media on a mounted+running system and could > be, for example, run via cron. > The FTL is supposed to take care of that. They typically have a scanning function that moves the data when it decays enough to be of concern... doing it at the LBA later is unlikely to produce satisfactory results. Such would not only be very useful to fix pending sectors without > stopping a running machine, but also for keeping embedded machines' > flash memories reliably charged over the years. > Not really.. Warner > On 7/5/18, Wojciech Puchar wrote: > >>> okay. What's the recommended action at this point? -- George > >> > >> In my experience it is begin of disk death, even if overall status is > >> PASSED. It could work for month or may be half a year after first > >> Offline_Uncorrectable is detected (it depends on load), but you best bet > >> to replace it ASAP and throw away. > > well my disk had this and live happily for 3 years. > > > > It JUST means that some sectors are unreadable which may be a reason that > > at some some write got wrong because of hardware problem. But this > problem > > may be - and possibly were - powerdown while writing, or power spike. > > > > the media itself could be fine. the best action in such case is to force > > rewrite whole drive with some data. > > > > with gmirror it is as easy as first checking second drive for no errors, > > then forcing remirror. > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu Jul 5 19:31:40 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CBEE1027B48 for ; Thu, 5 Jul 2018 19:31:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 619EF7265B; Thu, 5 Jul 2018 19:31:39 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id a134-v6so7880287lfe.6; Thu, 05 Jul 2018 12:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ELAPNVOcf0uZC1b6ry24PUHj3eD1aQRjyY9oYDeEdu8=; b=pMXSujDJxGuOt9js5MKJASMusx5zt2ZAbhhHfMDwwTMytCnltCBKoGEUS1I3Ill8MY gttHFZZf/G6iw67G1QuezcJ9IXVZJzefCNiaYfe8VhOf51l2AXC+staQWqAncswjx/EV g7ZEESN2vAmyH3IOgNTFWOOEsqf81GP5L4WzrZ7S4/+Qrf0PfR1MiGtaOfSYwje4Ga8E J2Bug40zunlXEnE8wq8fgiAwvSqp7WEvs/LYsQbUXHzXRTYlsA8cOtWYq1YoAwSyESwq uiIj/AnuhEtJrBQuZef5POt3567NbwfL51AwrX6ZIZku9fuN6J0MuySsjSMkjuttefZB 2m/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ELAPNVOcf0uZC1b6ry24PUHj3eD1aQRjyY9oYDeEdu8=; b=BON6dW0trcZFrqIFEyOnKCnlZr2FMjMaqGiqPDLS8mG8TZHziHJIkjQ6TqvGafVG1E D+2naQEH/1313U95EAjDXEZmMEn2P2kMJjt2xRa0NPtcht6/LtMne+0OdmBF3+a8InjQ qvccNFTmIgbFfQDqeUwLQ0NWKQZM1VakV85QbKJV60gkDM8Fi9oBp/iVCjGC1OOV7Ymt V0p2sNF/WXkGwmbCfxdlqXzNqQEWPVG6NDJYeEMT/lemLje/Nb0mbfeHUPvTBO3Cbd0H m196dfM9IoUGNyhq05gviqTFwRN6XX/yQmFVMKtDeD9FWuolIZAeLQVhdz3qZXxcGECh mFew== X-Gm-Message-State: APt69E0TZnI0m7iSVnTEc8Y+J4AxFcOC49OOp9Mt4DjG4iTpB8mb3/70 cEZVbTjf90FfRSpjyH2XQmhvTKEcG7DRlaWn6V0= X-Google-Smtp-Source: AAOMgpfF8LbO8IUngSGmC705ZP3yY4r6lKR+aXPqOwl6AcKKIbUozVxuErUmUeEC4BGCuq3HLusu2+dvYSvFEmg0qo8= X-Received: by 2002:a19:fc3:: with SMTP id 64-v6mr5503166lfp.46.1530819097781; Thu, 05 Jul 2018 12:31:37 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 2002:ab3:1b91:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 12:31:36 -0700 (PDT) In-Reply-To: <201807051815.w65IFqsB048887@pdx.rh.CN85.dnsmgr.net> References: <201807051815.w65IFqsB048887@pdx.rh.CN85.dnsmgr.net> From: Alan Somers Date: Thu, 5 Jul 2018 13:31:36 -0600 X-Google-Sender-Auth: VfkDKGzsiVvqs-GBKrd-Xga0Srw Message-ID: Subject: Re: Confusing smartd messages To: "Rodney W. Grimes" Cc: Wojciech Puchar , FreeBSD Hackers , Stefan Blachmann , Lev Serebryakov , George Mitchell Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 19:31:40 -0000 On Thu, Jul 5, 2018 at 12:15 PM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On Thu, Jul 5, 2018 at 11:03 AM, Wojciech Puchar > wrote: > > > > > > > >> Rewriting suspicious sectors is useless in this day and age. HDDs and > > >> SSDs > > >> already do it internally and have for years. Even healthy sectors get > > >> > > > > > > unreadable sectors cannot be rewritten by drive electronics as it > doesn't > > > know what to rewrite. it may possibly remap it but still report read > error > > > until some data will be written - unless giving no error and returning > > > meaningless data is an accepted behaviour. > > > > > > > But if that disk is already managed by ZFS, the pool is redundant, and > the > > bad sector is allocated by ZFS, then ZFS will immediately rewrite the > > unreadable sector. > > ZFS, if it gets a re error, will rewrite the unreadable sector > to a DIFFERENT block, not over the top of the bad spot. > Are you sure? For read errors, I think ZFS rewrites the data in-place, so it doesn't have to rewrite it on all other members of the same mirror/raid group. For persistent write errors of course, it would have to move it to a different LBA as you describe. > > > > only on write it can be done properly. > > > > > > that the HDD/SSD won't fix itself would be a checksum error. Those are > > >> > > > > > > yes and this will happen if you powerdown your disk on write. or get > some > > > power spike or other source of noise that would affect electronic > > > components. > > > > > > > It happens surprisingly rarely. Even on a sudden power loss, the drive > is > > usually able to finish its current write operation. When you run into > > problems would be if the power loss were coincident with a mechanical > shock > > that knocks the head off-track, or something like that. > > I agree that "power failure" are rare causes of write errors, and an > idea of how often this might of happened is look at the emergency > retract counter, if your gettng lots of those you should try to find > out why and stop that. Vibration has become a serious problem though, > at todays head flight hight drives are sensitive to this, you can > even cause a drive to do retires by yelling at it with a loud > voice :-) Look at the "high fly" counter to see if your getting > this issue. > > > > performing full disk rewrite (so not zfs rebuilds) and THEN looking at > > > smart stats and THEN performing regular smartctl -t long will tell the > > > truth. > > > > > > which usually is "drive is fine" in my practice. really faulty drive > will > > > QUICKLY develop new problems. > > > > > > > Yeah, that should make the error go away. It takes a long time, though. > > With a SCSI drive, you can get the exact LBAs affected with a "READ > > DEFECTS" command. But there isn't a vendor-independent equivalent for > > SATA, unfortunately. > > My bitch exactly about ATA missing this. Though there are vendor specific > commands to get it. > > -- > Rod Grimes > rgrimes@freebsd.org > From owner-freebsd-hackers@freebsd.org Fri Jul 6 01:06:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 717B11023102 for ; Fri, 6 Jul 2018 01:06:18 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E95D3804DA; Fri, 6 Jul 2018 01:06:17 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w6616DIm049981; Thu, 5 Jul 2018 18:06:13 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w6616Bs4049980; Thu, 5 Jul 2018 18:06:11 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201807060106.w6616Bs4049980@pdx.rh.CN85.dnsmgr.net> Subject: Re: Confusing smartd messages In-Reply-To: To: Alan Somers Date: Thu, 5 Jul 2018 18:06:11 -0700 (PDT) CC: Wojciech Puchar , FreeBSD Hackers , Stefan Blachmann , Lev Serebryakov , George Mitchell X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 01:06:18 -0000 [ Charset UTF-8 unsupported, converting... ] > On Thu, Jul 5, 2018 at 12:15 PM, Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > On Thu, Jul 5, 2018 at 11:03 AM, Wojciech Puchar > > wrote: > > > > > > > > > > >> Rewriting suspicious sectors is useless in this day and age. HDDs and > > > >> SSDs > > > >> already do it internally and have for years. Even healthy sectors get > > > >> > > > > > > > > unreadable sectors cannot be rewritten by drive electronics as it > > doesn't > > > > know what to rewrite. it may possibly remap it but still report read > > error > > > > until some data will be written - unless giving no error and returning > > > > meaningless data is an accepted behaviour. > > > > > > > > > > But if that disk is already managed by ZFS, the pool is redundant, and > > the > > > bad sector is allocated by ZFS, then ZFS will immediately rewrite the > > > unreadable sector. > > > > ZFS, if it gets a re error, will rewrite the unreadable sector > > to a DIFFERENT block, not over the top of the bad spot. > > > > Are you sure? For read errors, I think ZFS rewrites the data in-place, so > it doesn't have to rewrite it on all other members of the same mirror/raid > group. For persistent write errors of course, it would have to move it to > a different LBA as you describe. Your right, I am not sure exactly what happens during a scrub that finds a checksum error, or encounters a low level device I/O error. I was wrongly assuming that given the COW nature of the whole system that it would never overwrite anything. I wonder if you can send ZFS into a loop with a hard write failing sector. > > > > > > > only on write it can be done properly. > > > > > > > > that the HDD/SSD won't fix itself would be a checksum error. Those are > > > >> > > > > > > > > yes and this will happen if you powerdown your disk on write. or get > > some > > > > power spike or other source of noise that would affect electronic > > > > components. > > > > > > > > > > It happens surprisingly rarely. Even on a sudden power loss, the drive > > is > > > usually able to finish its current write operation. When you run into > > > problems would be if the power loss were coincident with a mechanical > > shock > > > that knocks the head off-track, or something like that. > > > > I agree that "power failure" are rare causes of write errors, and an > > idea of how often this might of happened is look at the emergency > > retract counter, if your gettng lots of those you should try to find > > out why and stop that. Vibration has become a serious problem though, > > at todays head flight hight drives are sensitive to this, you can > > even cause a drive to do retires by yelling at it with a loud > > voice :-) Look at the "high fly" counter to see if your getting > > this issue. > > > > > > performing full disk rewrite (so not zfs rebuilds) and THEN looking at > > > > smart stats and THEN performing regular smartctl -t long will tell the > > > > truth. > > > > > > > > which usually is "drive is fine" in my practice. really faulty drive > > will > > > > QUICKLY develop new problems. > > > > > > > > > > Yeah, that should make the error go away. It takes a long time, though. > > > With a SCSI drive, you can get the exact LBAs affected with a "READ > > > DEFECTS" command. But there isn't a vendor-independent equivalent for > > > SATA, unfortunately. > > > > My bitch exactly about ATA missing this. Though there are vendor specific > > commands to get it. > > > > -- > > Rod Grimes > > rgrimes@freebsd.org > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri Jul 6 01:28:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CEC91025A98 for ; Fri, 6 Jul 2018 01:28:58 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71A9C813C7; Fri, 6 Jul 2018 01:28:57 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-x243.google.com with SMTP id u7-v6so5343771lji.3; Thu, 05 Jul 2018 18:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=V2dVobBq7YLhACj1Xbh6idiEc+CPaexgGE0d2+hkYww=; b=HcaGZ111kZXNkWwBrdy8z0CAY6yyM5XX/aPaaxfnSR5ABqUy0bT5WueD4aGKkVPBKk F+YgH4U7K2q/+nGA2K7bfrXgFn6ioj2w207CsVfqBwnFIDOJorNQ9FMPW26FMftP3L2C T4sH3LD8BV3X7In884a/YbP3itCwYFO7kAsZA6690HsK+FKWLUPp/ld0h2R52bK5HuZc BQ5p1EoT5JIfRhoivIZ7k/eroX8u/Zbdlf/txI9zfK5D8qXmIB/GkXPd6Q9RvWV3EekO UPwG+7n5M4SGOmnEUuoXPSgCpFUzpy3ZwTa71zDaf/hLGKLo1SPcKBs5e9dbEGXCdTy2 ZP6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=V2dVobBq7YLhACj1Xbh6idiEc+CPaexgGE0d2+hkYww=; b=gOuoG9v35rZEGjgaVhwBZ7Y6YGSGzxgSiG0OKG2Tvx3/asLo3WGL4bRANmQXOG6x0+ 36mxN/QXhRR9bzo02sWzKw9vfL1RtIapJSNOW696XjBUy5r23+zxM3RYFmsuXsHw63B6 NMgec2cuaTPXd76a0jHxcGjCBuxu2v1/0pTKECvGRc545RKLj+TmCb1flYc/5gSQR0Kl i1frFusZbW0wZf8IZK4TFu3lzam3KqwgvBiFikVWXcX61p5eEAy+CTwWhnlqxpmhI0uS n50pZ7Bd+Cx5OaKzuZNjR/JHtkQxYxwPCHzyh6DXSeWD/yK9pPMRr1Pwh/lJXk+A4hk7 BpvA== X-Gm-Message-State: APt69E21DPTmuTLF636FlyL0lxspxa+/JAYE7fTMggYMd6Jqapuif4p7 qFjoeFfWsPf1pyxMlNLaZ9+jCX1sH/ZhunX0dp4= X-Google-Smtp-Source: AAOMgpfm3aPZfDzIL8+RHlV/eG0LQoTBLaypjeVoP31SbNphiSVjW2F5y04x0pyqbL54dltGV1/61VtO1rTrukdlnUk= X-Received: by 2002:a2e:44c6:: with SMTP id b67-v6mr5555312ljf.102.1530840536008; Thu, 05 Jul 2018 18:28:56 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 2002:ab3:1b91:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 18:28:55 -0700 (PDT) In-Reply-To: <201807060106.w6616Bs4049980@pdx.rh.CN85.dnsmgr.net> References: <201807060106.w6616Bs4049980@pdx.rh.CN85.dnsmgr.net> From: Alan Somers Date: Thu, 5 Jul 2018 19:28:55 -0600 X-Google-Sender-Auth: kMXWvTdbxbwS0-cs0H4q_vVtisM Message-ID: Subject: Re: Confusing smartd messages To: "Rodney W. Grimes" Cc: Wojciech Puchar , FreeBSD Hackers , Stefan Blachmann , Lev Serebryakov , George Mitchell Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 01:28:58 -0000 On Thu, Jul 5, 2018 at 7:06 PM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > [ Charset UTF-8 unsupported, converting... ] > > On Thu, Jul 5, 2018 at 12:15 PM, Rodney W. Grimes < > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > On Thu, Jul 5, 2018 at 11:03 AM, Wojciech Puchar > > > wrote: > > > > > > > > > > > > > >> Rewriting suspicious sectors is useless in this day and age. > HDDs and > > > > >> SSDs > > > > >> already do it internally and have for years. Even healthy > sectors get > > > > >> > > > > > > > > > > unreadable sectors cannot be rewritten by drive electronics as it > > > doesn't > > > > > know what to rewrite. it may possibly remap it but still report > read > > > error > > > > > until some data will be written - unless giving no error and > returning > > > > > meaningless data is an accepted behaviour. > > > > > > > > > > > > > But if that disk is already managed by ZFS, the pool is redundant, > and > > > the > > > > bad sector is allocated by ZFS, then ZFS will immediately rewrite the > > > > unreadable sector. > > > > > > ZFS, if it gets a re error, will rewrite the unreadable sector > > > to a DIFFERENT block, not over the top of the bad spot. > > > > > > > Are you sure? For read errors, I think ZFS rewrites the data in-place, > so > > it doesn't have to rewrite it on all other members of the same > mirror/raid > > group. For persistent write errors of course, it would have to move it > to > > a different LBA as you describe. > > Your right, I am not sure exactly what happens during a scrub that finds > a checksum error, or encounters a low level device I/O error. I was > wrongly > assuming that given the COW nature of the whole system that it would > never overwrite anything. > > I wonder if you can send ZFS into a loop with a hard write failing sector. > Not if you have zfsd enabled. zfsd will fault the device after too many errors. And even without zfsd, I think zfs must give up on that sector after awhile, but I'm not positive. If a single bad sector could cause an endless resilver loop, I think I would've seen it by now. > > > > > > > > > > > only on write it can be done properly. > > > > > > > > > > that the HDD/SSD won't fix itself would be a checksum error. > Those are > > > > >> > > > > > > > > > > yes and this will happen if you powerdown your disk on write. or > get > > > some > > > > > power spike or other source of noise that would affect electronic > > > > > components. > > > > > > > > > > > > > It happens surprisingly rarely. Even on a sudden power loss, the > drive > > > is > > > > usually able to finish its current write operation. When you run > into > > > > problems would be if the power loss were coincident with a mechanical > > > shock > > > > that knocks the head off-track, or something like that. > > > > > > I agree that "power failure" are rare causes of write errors, and an > > > idea of how often this might of happened is look at the emergency > > > retract counter, if your gettng lots of those you should try to find > > > out why and stop that. Vibration has become a serious problem though, > > > at todays head flight hight drives are sensitive to this, you can > > > even cause a drive to do retires by yelling at it with a loud > > > voice :-) Look at the "high fly" counter to see if your getting > > > this issue. > > > > > > > > performing full disk rewrite (so not zfs rebuilds) and THEN > looking at > > > > > smart stats and THEN performing regular smartctl -t long will tell > the > > > > > truth. > > > > > > > > > > which usually is "drive is fine" in my practice. really faulty > drive > > > will > > > > > QUICKLY develop new problems. > > > > > > > > > > > > > Yeah, that should make the error go away. It takes a long time, > though. > > > > With a SCSI drive, you can get the exact LBAs affected with a "READ > > > > DEFECTS" command. But there isn't a vendor-independent equivalent > for > > > > SATA, unfortunately. > > > > > > My bitch exactly about ATA missing this. Though there are vendor > specific > > > commands to get it. > > > > > > -- > > > Rod Grimes > > > rgrimes@freebsd.org > > > > > -- > Rod Grimes > rgrimes@freebsd.org > From owner-freebsd-hackers@freebsd.org Fri Jul 6 10:42:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B63E6103C6C7 for ; Fri, 6 Jul 2018 10:42:46 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 36439794DB for ; Fri, 6 Jul 2018 10:42:46 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id 49678BC4; Fri, 6 Jul 2018 13:42:44 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: Confusing smartd messages To: Wojciech Puchar Cc: George Mitchell , FreeBSD Hackers References: <51eb8232-49a7-0b3a-2d0f-9882ebfbfa1d@FreeBSD.org> From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: Date: Fri, 6 Jul 2018 13:42:43 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2018 10:42:47 -0000 On 05.07.2018 17:44, Wojciech Puchar wrote: > It JUST means that some sectors are unreadable which may be a reason > that at some some write got wrong because of hardware problem.But this > problem may be - and possibly were - powerdown while writing, or power > spike. Maybe, our experiences are different because all my computers with spinning media are always powered by good UPSes. And they never ever encounter "powerdown while writing" :-) So, for me single write error is sure indication of degrading HDD. Sometimes I was able to get free exchange on this basis, if guarantee is not expired yet, BTW. -- // Lev Serebryakov From owner-freebsd-hackers@freebsd.org Sat Jul 7 12:21:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B02BA103E5B6 for ; Sat, 7 Jul 2018 12:21:25 +0000 (UTC) (envelope-from munro@penski.net) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 32C9473DA0 for ; Sat, 7 Jul 2018 12:21:24 +0000 (UTC) (envelope-from munro@penski.net) Received: by mail-ed1-x52e.google.com with SMTP id a5-v6so10517044edt.5 for ; Sat, 07 Jul 2018 05:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=penski-net.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=J+PIzjZ9lUG0Esy1mdW2N2bxp5lt4puGVgGFny5lX88=; b=chiGERjNOCrFOn6Nc53HYcole7iL6ii/9iJoxt4ygWMk+poH7FwuTrkNu7ymnfmxiK t+Wg7bHnOHmRW6LTvtehQ46vWNFabvKAx66IkPg6J0aeDSoNx2H1sWlK4X0SoFz7BWzO /yIZLPR6LlP1jnrr0UKyCsIDcuSl73Tip8DCFT0OH4t5dDNl/48Ix9ibcePoD+Rdrefy 5gg8fD4HWKUoBkhIxUkOg0LsBFMzZrv51SqDyman2lF0YQAItVqTKt1ZeCq7PPJ4yM/Z LZQc7ip7eN+NsC9AULQDeWVoVDcpqLt0QrAgjCjqyhTWspgdrL83+4G+uZfFORfIcntq /fqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=J+PIzjZ9lUG0Esy1mdW2N2bxp5lt4puGVgGFny5lX88=; b=jvD3nqKiImuOcN2+uTCMV8zuAqWT3HtBxdnXBPOaGPe4ybUBzlMtIpdd2begpBrxt4 /GO8r1DqkaP0gjZ83VcetlsLWKenVLU9jUcWbzDvUsKeZdNlOcR+/oxEZaElHiM/6CbT ziUumktlXWYOvjK0A0zIPCMA0DQ8PtQFb62zAdISmVfoB6CqdZFXUHdajpT8kBF2G+Q9 ZNg/UeJ+En9M5MPXp2F/aGOR2frkdOAnryHWr37/RHMigc9XdmeNpu86Aa6HIns9NwWp E9XevxzZWOpED787riK2oEUnByIZWKHRs4JJyHtcgeWQvA2JjQ/fMTQTYk/RCbSbl9pt i6EQ== X-Gm-Message-State: APt69E09By/GIbFABffnjVfMfOaWkRFQ4+TTTmBhmIxwadU5SKQXDeJH wkidwG93gzwPLjqXBE3DJ9t5pvgaO3xRkMK+6leTBs5R X-Google-Smtp-Source: AAOMgpfeZ4IPr8nDysdBUWWu+WaXFm0tH2I525JODWX9f7VppvDzg9ovY/+FXRs5bKy99loPXD0a2g6IQPF803ONKBU= X-Received: by 2002:aa7:d786:: with SMTP id s6-v6mr11518102edq.228.1530966083058; Sat, 07 Jul 2018 05:21:23 -0700 (PDT) MIME-Version: 1.0 Sender: munro@penski.net Received: by 2002:a50:a1c7:0:0:0:0:0 with HTTP; Sat, 7 Jul 2018 05:21:22 -0700 (PDT) X-Originating-IP: [121.73.38.77] From: Thomas Munro Date: Sun, 8 Jul 2018 00:21:22 +1200 X-Google-Sender-Auth: FgVQx111n8RaX9sif1YrgnvaRRE Message-ID: Subject: Adding an "expose_authtok" option to pam_exec(8) To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2018 12:21:25 -0000 Hello, On Linux, pam_exec.so has an option "expose_authtok" which causes the authentication token to be sent to the executed program's stdin. That's quite a useful bridge to languages other than C that want to check the password or use it to decrypt something etc, since otherwise you have to provide some kind of .so wrapper providing the PAM C API to get at that. I wrote a patch to implement that and posted it here: https://reviews.freebsd.org/D16171 . I'd be grateful for any feedback. Thanks, Thomas Munro