On Fri, 27 Nov 2020 07:34:32 +0100 Gary Jennejohn <gljennj...@gmail.com> wrote:
> On Thu, 26 Nov 2020 20:09:41 +0100 > Michael Gmelin <free...@grem.de> wrote: > > > > On 26. Nov 2020, at 19:21, Gary Jennejohn <gljennj...@gmail.com> wrote: > > > > > > ___On Thu, 26 Nov 2020 10:44:19 -0700 > > > Warner Losh <i...@bsdimp.com> wrote: > > > > > >>> On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin <free...@grem.de> wrote: > > >>> > > >>> > > >>> > > >>> On Thu, 26 Nov 2020 10:12:06 +0100 > > >>> Gary Jennejohn <gljennj...@gmail.com> wrote: > > >>> > > >>>> On Thu, 26 Nov 2020 01:14:02 -0700 > > >>>> Warner Losh <i...@bsdimp.com> wrote: > > >>>> > > >>>>> On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn > > >>>>> <gljennj...@gmail.com> wrote: > > >>>>>> On Thu, 26 Nov 2020 00:10:40 +0000 > > >>>>>> tech-lists <tech-li...@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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
