From owner-freebsd-current@freebsd.org Thu Nov 26 18:21:13 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 DF38946BD0A for ; Thu, 26 Nov 2020 18:21:13 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ChmKh6ntHz4rXP for ; Thu, 26 Nov 2020 18:21:12 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id u12so3139163wrt.0 for ; Thu, 26 Nov 2020 10:21:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=HBTa2nibAXha+fnEKe/Im1MHPsg12Fc38aznAru3Auc=; b=JllxTX0wfrHJchcjJJODLd2UGykZJx64uHWvPo2oIb2jxrUkuSddbpljDuBt6buizz zgzgNP065jufyHDFKcXoCaNb4ad1/ZlLN8s50X49OVA1A4fO94ssUWbjq0Ix3tUXMt8j XIulR7vMjkEZW5Bhk8FWItJYgeK9QmYGva/A5lgMGgCuyPYJKENYNEHOuzMO1O96v4bE mc797pfGHXYMlD0aYoYZoKD7fBYijFBwv6G+3hUUHa/xgYG0hDo9bRwTDBnVEbFWvLwn GcvrwLk6VmeIlQpOZaDBJIU4ApzgWGvA9A4Es6KdgWaMc9rFrO2BZdjr1GMQQjrifX3o 7J/g== X-Gm-Message-State: AOAM53055DW9vwHP/QNHxSUCs+oZpAZFFpepXVRRtV7xFL7CPRZcxQp5 ay8ceoufz5XOl/vXP9Kgut6ZvYMs354= X-Google-Smtp-Source: ABdhPJzsBbrCgms95XD/0SeogTfi0yBFIoTqDjpIvSqfJie8DDXxLtgUEOvC1XtP3jO04Z+UCJYKIQ== X-Received: by 2002:adf:ec8a:: with SMTP id z10mr5545385wrn.113.1606414870540; Thu, 26 Nov 2020 10:21:10 -0800 (PST) Received: from ernst.home (p5b02350e.dip0.t-ipconnect.de. [91.2.53.14]) by smtp.gmail.com with ESMTPSA id g138sm9394114wme.39.2020.11.26.10.21.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Nov 2020 10:21:09 -0800 (PST) Date: Thu, 26 Nov 2020 19:21:08 +0100 From: Gary Jennejohn To: FreeBSD Current Subject: Re: possible usb3-connected hard drive spin down causing lag Message-ID: <20201126182108.4314a0aa@ernst.home> In-Reply-To: References: <20201126080724.1cb3a8af@ernst.home> <20201126091206.0dcd5b33@ernst.home> <20201126121623.31ea2cd3@bsd64.grem.de> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4ChmKh6ntHz4rXP X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.32 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::431:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[91.2.53.14:received]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; FREEMAIL_REPLYTO(0.00)[gmail.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::431:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.68)[0.677]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; 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 18:21:13 -0000 On Thu, 26 Nov 2020 10:44:19 -0700 Warner Losh wrote: > On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin wrote: > > > > > > > On Thu, 26 Nov 2020 10:12:06 +0100 > > Gary Jennejohn wrote: > > > > > On Thu, 26 Nov 2020 01:14:02 -0700 > > > Warner Losh wrote: > > > > > > > On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn > > > > wrote: > > > > > On Thu, 26 Nov 2020 00:10:40 +0000 > > > > > tech-lists wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I have a usb3-connected harddrive. dmesg shows this: > > > > > > [...] > > > > > > da0: Fixed Direct Access SPC-4 SCSI device > > > > > > [...] > > > > > > > > > > > > running current-r367806-arm64 > > > > > > > > > > > > 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. > > > > > > > > > > > > I have vfs.read_max=128 in /etc/sysctl.conf > > > > > > zdb has ashift=12 > > > > > > > > > > > > In case it's relevant, the filesystem on the disk is zfs. Once > > > > > > "woken up", inferaction is quick, as expected. > > > > > > thanks, > > > > > > > > > > > > > > > > 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. > > > > > > > > > > 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. > > > > > > > > > > This behavior makes sense for drives used with laptops, but for > > > > > desktop computers not so useful. > > > > > > > > > > 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: > > > > > > > > > > kern.cam.ada.spindown_suspend: Spin down upon suspend > > > > > kern.cam.ada.spindown_shutdown: Spin down upon shutdown > > > > > > > > > > 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. > > > > > > > > For SAS drives, there's a mode page that controls this behavior. > > > > > > > > You might see if the sysutil/ataidle port/package does what you > > > > want. > > > > > > 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? > > > > > > My disks are all SATA in various USB3 enclosures/docking stations. > > > > > > > I also used ataidle in the past, but it was removed from the ports tree > > in 2018 (see MOVED). > > > > Since then, I'm using camcontrol to set standby timeout values on my > > SATA drives, I never tried it on USB devices though. > > > > Example: > > > > /sbin/camcontrol standby /dev/da2 -v -t 1800 > > > 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. > 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 a PITA. -- Gary Jennejohn