From owner-freebsd-current@freebsd.org Fri Nov 27 06:52:17 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 E4F7847EFAF for ; Fri, 27 Nov 2020 06:52:17 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 4Cj50K1qcpz4gcw for ; Fri, 27 Nov 2020 06:52:17 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm1-x32c.google.com with SMTP id w24so5521059wmi.0 for ; Thu, 26 Nov 2020 22:52:17 -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=ZCTp4f+SscCf3bV0nd13hhE299/L8eSf5n7outJCGkw=; b=Xgmge/p8b0LrRkD3u+peVcEULXhsQaKXSH/TNf2siPcNLCEvqdWK0p2+Q8/qxt+2GV qN4adrp9kP16AzeG5oEobWrVPmLWc+CMEUrJQ1ZXSdS56sGWmKSPrQgjOwvFTjh+sj55 +q3vwXkA3MXHstaHXfZ/B2wD0x1XjSPbzAJJ1BRtJwTwyISdTKzOxhpy+/dM1GUHIWaf mGDNOQ87Xl39pm6fFOhLYiNw0Yq8u5htvsxGIjyy9pw1yHPj3F5uPrbASqzidQ3EvRdS rCtmWfLVzPaqBY4wYhsX2YrvtqLgpggnC8JfZb9hOtNm3a1gW54RdLejwWFS+5nAOlzk lcSg== X-Gm-Message-State: AOAM531fKG3g2jRU2xXZ9X19XJTgptZTdjYNfoF5MMcqClDS4pgs9oYY z7a+V1F9Y0zyt2oDo7S6pSyuxm6tKAo= X-Google-Smtp-Source: ABdhPJwnOdPoGFfTdEi2c9IFHzgqg+SLEbheI9khr14E+FTrn/6xKC9pqwSW7qik4vyeIIGo3QsLpQ== X-Received: by 2002:a05:600c:2110:: with SMTP id u16mr7316654wml.4.1606459935588; Thu, 26 Nov 2020 22:52:15 -0800 (PST) Received: from ernst.home (p5b02350e.dip0.t-ipconnect.de. [91.2.53.14]) by smtp.gmail.com with ESMTPSA id l13sm12584196wrm.24.2020.11.26.22.52.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Nov 2020 22:52:14 -0800 (PST) Date: Fri, 27 Nov 2020 07:52:13 +0100 From: Gary Jennejohn To: FreeBSD Current Subject: Re: possible usb3-connected hard drive spin down causing lag Message-ID: <20201127065213.449920b2@ernst.home> In-Reply-To: <20201127063432.590c387f@ernst.home> References: <20201126182108.4314a0aa@ernst.home> <6D7FEFE1-FF63-4920-9BA8-C8DCBE3D4019@grem.de> <20201127063432.590c387f@ernst.home> 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: 4Cj50K1qcpz4gcw X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 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]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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::32c: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::32c:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32c: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: Fri, 27 Nov 2020 06:52:18 -0000 On Fri, 27 Nov 2020 07:34:32 +0100 Gary Jennejohn wrote: > On Thu, 26 Nov 2020 20:09:41 +0100 > Michael Gmelin wrote: > > > > On 26. Nov 2020, at 19:21, Gary Jennejohn wrote: > > > > > > ___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. > > > > Does using /dev/passX instead of /dev/daX make a difference? (I > > remember I had to do something like this when using smartctl on usb > > drives). > > > > No, the bridge controller still idles the disk after a few minutes. > > But I tried it with camcontrol idle rather than standby. Trying > standby does send a ATA STANDBY command to pass0. Maybe that will > work. > Now I see that I misunderstood the meaning of the -t flag. Using the -v flag I noticed that using -t 0 actually sets the timeout to only 30 seconds. I've now tried the idle and standby commands with -t 600 (10 minutes). So, I'll have to wait and see whether that works. -- Gary Jennejohn