possible usb3-connected hard drive spin down causing lag
Gary Jennejohn
gljennjohn at gmail.com
Fri Nov 27 06:34:36 UTC 2020
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.
--
Gary Jennejohn
More information about the freebsd-current
mailing list