From owner-freebsd-questions@freebsd.org Sat Mar 28 03:03:14 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 034FD26DA33 for ; Sat, 28 Mar 2020 03:03:14 +0000 (UTC) (envelope-from dpchrist@holgerdanske.com) Received: from holgerdanske.com (holgerdanske.com [184.105.128.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "holgerdanske.com", Issuer "holgerdanske.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48q3SS58Jzz4p8X for ; Sat, 28 Mar 2020 03:03:04 +0000 (UTC) (envelope-from dpchrist@holgerdanske.com) Received: from 99.100.19.101 ([99.100.19.101]) by holgerdanske.com with ESMTPSA (ECDHE-RSA-AES128-GCM-SHA256:TLSv1.2:Kx=ECDH:Au=RSA:Enc=AESGCM(128):Mac=AEAD) (SMTP-AUTH username dpchrist@holgerdanske.com, mechanism PLAIN) for ; Fri, 27 Mar 2020 18:46:42 -0700 Subject: Re: drive selection for disk arrays To: freebsd-questions@freebsd.org References: <20200325081814.GK35528@mithril.foucry.net> <713db821-8f69-b41a-75b7-a412a0824c43@holgerdanske.com> <20200326124648725158537@bob.proulx.com> <20200327104555.1d6d7cd9.freebsd@edvax.de> <1bcd7aa2-31e5-91f1-5151-926c9d16e16e@holgerdanske.com> <8e74482f-b951-ee97-50b8-04ea1f0d46a3@denninger.net> From: David Christensen Message-ID: Date: Fri, 27 Mar 2020 18:46:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <8e74482f-b951-ee97-50b8-04ea1f0d46a3@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 48q3SS58Jzz4p8X X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of dpchrist@holgerdanske.com has no SPF policy when checking 184.105.128.27) smtp.mailfrom=dpchrist@holgerdanske.com X-Spamd-Result: default: False [-1.05 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.63)[-0.631,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(-0.60)[ipnet: 184.104.0.0/15(0.62), asn: 6939(-3.59), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.71)[-0.710,0]; DMARC_NA(0.00)[holgerdanske.com]; RCVD_IN_DNSWL_NONE(0.00)[27.128.105.184.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:184.104.0.0/15, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2020 03:03:14 -0000 On 2020-03-27 17:45, Karl Denninger wrote: > > On 3/27/2020 19:39, David Christensen wrote: >> On 2020-03-27 02:45, Polytropon wrote: >> >>> When a drive _reports_ bad sectors, at least in the past >>> it was an indication that it already _has_ lots of them. >>> The drive's firmware will remap bad sectors to spare >>> sectors, so "no error" so far. >> >> If a drive detects an error, my guess is that it will report the error >> to the OS; regardless of the outcome of a particular I/O operation >> (data read, data written, data lost) or internal actions taken (block >> marked bad, block remapped, etc.).  It is then up to the OS to decide >> what to do next.  RAID and/or ZFS offer the means for shielding the >> application from I/O and drive failures. >> > Yes, but... > > Those drives that can do "SMART" will report (if you have a patrol > daemon for it running) if they do a "silent" sector reassignment. > Otherwise the OS is none the wiser and neither is ZFS (or anything > else.) I guess I need to RTFM: https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/serial-ata-ahci-spec-rev1-3-1.pdf > Needless to say if reassignments increase you might want to > think about swapping the drive *before* it blows up! Agreed. > I have the daemon running on all my machines.  It works nicely and has > warned me a few times over the years.  With that said it doesn't ALWAYS > catch a drive before it pukes. Are you referring to periodic, smartd, or something else? # pkg install smartmontools Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 1 package(s) will be affected (of 0 checked): New packages to be INSTALLED: smartmontools: 7.0_2 Number of packages to be installed: 1 The process will require 2 MiB more space. 495 KiB to be downloaded. [1/1] Fetching smartmontools-7.0_2.txz: 100% 495 KiB 507.1kB/s 00:01 Checking integrity... done (0 conflicting) [1/1] Installing smartmontools-7.0_2... [1/1] Extracting smartmontools-7.0_2: 100% ===== Message from smartmontools-7.0_2: -- smartmontools has been installed To check the status of drives, use the following: /usr/local/sbin/smartctl -a /dev/ad0 for first ATA/SATA drive /usr/local/sbin/smartctl -a /dev/da0 for first SCSI drive /usr/local/sbin/smartctl -a /dev/ada0 for first SATA drive To include drive health information in your daily status reports, add a line like the following to /etc/periodic.conf: daily_status_smart_devices="/dev/ad0 /dev/da0" substituting the appropriate device names for your SMART-capable disks. To enable drive monitoring, you can use /usr/local/sbin/smartd. A sample configuration file has been installed as /usr/local/etc/smartd.conf.sample Copy this file to /usr/local/etc/smartd.conf and edit appropriately To have smartd start at boot echo 'smartd_enable="YES"' >> /etc/rc.conf David