possible usb3-connected hard drive spin down causing lag

[Michael Gmelin]

> 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).

-m


> 
> -- 
> Gary Jennejohn
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"