From owner-freebsd-current@freebsd.org Thu Nov 26 19:09:50 2020 Return-Path: Delivered-To: freebsd-current@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 5441746D270 for ; Thu, 26 Nov 2020 19:09:50 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ChnPn0bp6z4vJK; Thu, 26 Nov 2020 19:09:48 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 2af3f24d; Thu, 26 Nov 2020 19:09:45 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id b3101c52 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Thu, 26 Nov 2020 19:09:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: possible usb3-connected hard drive spin down causing lag From: Michael Gmelin In-Reply-To: <20201126182108.4314a0aa@ernst.home> Date: Thu, 26 Nov 2020 20:09:41 +0100 Cc: FreeBSD Current Message-Id: <6D7FEFE1-FF63-4920-9BA8-C8DCBE3D4019@grem.de> References: <20201126182108.4314a0aa@ernst.home> To: gljennjohn@gmail.com X-Mailer: iPhone Mail (18B92) X-Rspamd-Queue-Id: 4ChnPn0bp6z4vJK X-Spamd-Bar: / X-Spamd-Result: default: False [-1.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:213.239.217.29/32]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[grem.de:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[213.239.217.29:from]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; FORGED_RECIPIENTS(2.00)[m:gljennjohn@gmail.com,s:grembo@freebsd.org]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[grem.de:s=20180501]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grem.de]; SPAMHAUS_ZRD(0.00)[213.239.217.29:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 19:09:50 -0000 > On 26. Nov 2020, at 19:21, Gary Jennejohn wrote: >=20 > =EF=BB=BFOn Thu, 26 Nov 2020 10:44:19 -0700 > Warner Losh wrote: >=20 >>> On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin wrote: >>>=20 >>>=20 >>>=20 >>> On Thu, 26 Nov 2020 10:12:06 +0100 >>> Gary Jennejohn wrote: >>>=20 >>>> On Thu, 26 Nov 2020 01:14:02 -0700 >>>> Warner Losh wrote: >>>>=20 >>>>> On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn >>>>> wrote: =20 >>>>>> On Thu, 26 Nov 2020 00:10:40 +0000 >>>>>> tech-lists wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> I have a usb3-connected harddrive. dmesg shows this: >>>>>>> [...] >>>>>>> da0: Fixed Direct Access SPC-4 SCSI device >>>>>>> [...] >>>>>>>=20 >>>>>>> running current-r367806-arm64 >>>>>>>=20 >>>>>>> I think it might be auto-spinning-down or auto-sleeping. It's >>>>>>> making initial interaction lag of 2-3 seconds. Is there a >>>>>>> sysctl or something somewhere where I can tell it to never >>>>>>> sleep? Or is that something I'd need to contact the >>>>>>> manufacturer about? Or is there an alternative strategy like >>>>>>> tmpfs. It's not a "green" drive but I guess it might be >>>>>>> "green" in that it's usb3 powered. >>>>>>>=20 >>>>>>> I have vfs.read_max=3D128 in /etc/sysctl.conf >>>>>>> zdb has ashift=3D12 >>>>>>>=20 >>>>>>> In case it's relevant, the filesystem on the disk is zfs. Once >>>>>>> "woken up", inferaction is quick, as expected. >>>>>>> thanks, >>>>>>>=20 >>>>>>=20 >>>>>> I'd be interested in an answer to this question myself. I have >>>>>> several USB-attached UFS2 disks which spin down after a few >>>>>> minutes. >>>>>>=20 >>>>>> But, based on some quick searches, this behavior is either a >>>>>> "feature" of the disk itself - seems common with so-called green >>>>>> disks - or of the controller in the external enclosure or docking >>>>>> station. >>>>>>=20 >>>>>> This behavior makes sense for drives used with laptops, but for >>>>>> desktop computers not so useful. >>>>>>=20 >>>>>> There are some sysctl's relevant to spindown, but they appear to >>>>>> only come into play during suspend or shutdown. The ones >>>>>> relevant to USB which I found are: >>>>>>=20 >>>>>> kern.cam.ada.spindown_suspend: Spin down upon suspend >>>>>> kern.cam.ada.spindown_shutdown: Spin down upon shutdown >>>>>>=20 >>>>>> There may be commands which a user can send the disk/controller to >>>>>> disable this behavior, but I didn't find any with my simple >>>>>> searches. =20 >>>>>=20 >>>>> For SAS drives, there's a mode page that controls this behavior. >>>>>=20 >>>>> You might see if the sysutil/ataidle port/package does what you >>>>> want. =20 >>>>=20 >>>> Thanks, Warner, but that port is not in my HEAD ports tree. It's >>>> also not in the HEAD pkg repository. Many the name has changed? >>>>=20 >>>> My disks are all SATA in various USB3 enclosures/docking stations. >>>>=20 >>>=20 >>> I also used ataidle in the past, but it was removed from the ports tree >>> in 2018 (see MOVED). >>>=20 >>> Since then, I'm using camcontrol to set standby timeout values on my >>> SATA drives, I never tried it on USB devices though. >>>=20 >>> Example: >>>=20 >>> /sbin/camcontrol standby /dev/da2 -v -t 1800 =20 >>=20 >>=20 >> Perfect! I've not had to deal with sata disks that did this since the >> ataidle days. I looked in camcontrol before suggesting it, but somehow >> missed this... Glad I posted a bogus answer (sorry about that), since I >> learned something new. >>=20 >=20 > camcontrol unfortuantely doesn't work with my USB3 enclosures. I > suspect that the USB3-to-SATA bridge controller is doing its own thing > and camcontrol has no effect on its behavior. Not tragic for me since > I use these disks primarily for backups. But for someone using a USB > attached disk as a primary file system this behavior will definitely be=20= > a PITA. Does using /dev/passX instead of /dev/daX make a difference? (I remember I h= ad to do something like this when using smartctl on usb drives). -m >=20 > --=20 > Gary Jennejohn > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"=