possible usb3-connected hard drive spin down causing lag

[Gary Jennejohn]

On Fri, 27 Nov 2020 07:34:32 +0100
Gary Jennejohn <gljennjohn at gmail.com> wrote:

> On Thu, 26 Nov 2020 20:09:41 +0100
> Michael Gmelin <freebsd at grem.de> wrote:
> 
> > > On 26. Nov 2020, at 19:21, Gary Jennejohn <gljennjohn at gmail.com> wrote:
> > > 
> > > ___On Thu, 26 Nov 2020 10:44:19 -0700
> > > Warner Losh <imp at bsdimp.com> wrote:
> > >     
> > >>> On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin <freebsd at grem.de> wrote:
> > >>> 
> > >>> 
> > >>> 
> > >>> On Thu, 26 Nov 2020 10:12:06 +0100
> > >>> Gary Jennejohn <gljennjohn at gmail.com> wrote:
> > >>>     
> > >>>> On Thu, 26 Nov 2020 01:14:02 -0700
> > >>>> Warner Losh <imp at bsdimp.com> wrote:
> > >>>>     
> > >>>>> On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn
> > >>>>> <gljennjohn at gmail.com> wrote:      
> > >>>>>> On Thu, 26 Nov 2020 00:10:40 +0000
> > >>>>>> tech-lists <tech-lists at zyxst.net> wrote:
> > >>>>>>     
> > >>>>>>> Hi,
> > >>>>>>> 
> > >>>>>>> I have a usb3-connected harddrive. dmesg shows this:
> > >>>>>>> [...]
> > >>>>>>> da0: <ADATA HD710 0> 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