From owner-freebsd-current@freebsd.org Fri Nov 27 06:34:36 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 762B747E9D7 for ; Fri, 27 Nov 2020 06:34:36 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 4Cj4bw2g2Wz4fq4 for ; Fri, 27 Nov 2020 06:34:36 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wm1-x32a.google.com with SMTP id x22so4152545wmc.5 for ; Thu, 26 Nov 2020 22:34:36 -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:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=PpGwWcxyaaontsgcbscALBWH1Ss329VjyWev2FFQe24=; b=iznqpsSWb/UpowqIhRK9Gx1xsVYa8Dfbl+UMJ3UvhWFNvtjLMZ707c3rrzgEn0zc8M DNefbbiEVM1v+JpA5sEgU7X8dZ+0pG1gjHq/GLTsR8nURvh2xP0majmFEnUduNFdEH1z 8V8JapZyPxgTzv6jQA23FkGQ5Al2D7qQsB0l4Myzy6p8pvANq3lvABdS7FDJd/OOPQSL 2G0kdw7ZxdqrBu4ZTav2TDghWUCUpCvLd0iFiJgqk/G/LdjSiZl4kBxu608H+Yp1YkFK Lk8IIBWUU9mMEHCNMAAn3dcswdKFr5Um0FxdVvg4ZVzuEN6AKQnto+sPt8ZPOSPA7kds OG5w== X-Gm-Message-State: AOAM530tRo1XquLtiB+SYA8gR4c0j51zN9WWvpGr/zwj6RS7kH3Odom8 J+NSi9o8wktOnKV/tNmFHhk= X-Google-Smtp-Source: ABdhPJzx6KcNfywNxgna28nvhv3oZxJiGPOBhk+WrGhwqY7qR0mIs7YBlAQiYRQtxBMfy41fXQPI2w== X-Received: by 2002:a05:600c:229a:: with SMTP id 26mr7267589wmf.100.1606458874827; Thu, 26 Nov 2020 22:34:34 -0800 (PST) Received: from ernst.home (p5b02350e.dip0.t-ipconnect.de. [91.2.53.14]) by smtp.gmail.com with ESMTPSA id j8sm12897083wrx.11.2020.11.26.22.34.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Nov 2020 22:34:34 -0800 (PST) Date: Fri, 27 Nov 2020 07:34:32 +0100 From: Gary Jennejohn To: Michael Gmelin Cc: FreeBSD Current Subject: Re: possible usb3-connected hard drive spin down causing lag Message-ID: <20201127063432.590c387f@ernst.home> In-Reply-To: <6D7FEFE1-FF63-4920-9BA8-C8DCBE3D4019@grem.de> References: <20201126182108.4314a0aa@ernst.home> <6D7FEFE1-FF63-4920-9BA8-C8DCBE3D4019@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: 4Cj4bw2g2Wz4fq4 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] 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:34:36 -0000 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. -- Gary Jennejohn