> 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"Received on Thu Nov 26 2020 - 18:09:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC