Re: possible usb3-connected hard drive spin down causing lag
On Fri, Nov 27, 2020 at 04:34:24PM +0100, Ronald Klop wrote: Mind to share these tips, so I can use them on my RPI4? ;-) sure! I'll write up a simple site later, but in summary this is what I've done subsequent to the initial setup. E&OE, if it breaks you get to keep both bits, no guarantees etc etc. In no particular order: 1. in /boot/msdos/config.txt there's this: over_voltage=6 arm_freq=2000 sdram_freq_min=3200 [I use a FLIRC case to keep it cool. you *must* use cooling for this. Max temps I'm seeing under very heavy compiling (it runs poudriere) is 72 degC in 25 degC ambient] 2. /usr/src /usr/ports /usr/local /usr/obj /home /var/cache/ccache are all on the usb3 disk, seperate datasets. 3. swap is 16GB and is the first partition on the usb3 disk 4. for compiling, ccache is a must. 5. set tmp to tmpfs in /etc/fstab. I use 1GB like this: tmpfs /tmp tmpfs rw,mode=1777,size=1024m 0 0 6. make things like mutt use this /tmp 7. enable powerd and on bootup. Make it almost always use the overclocked speed like this in /etc/rc.conf powerd_enable="YES" powerd_flags="-r 1" This makes it run @ 2GHz always without needing to set something like boost_turbo. 8. in /etc/sysctl.conf: vfs.read_max=128 # default 64 9. compile mutt with kyotocabinet which uses (I think) memory mapping for cache lookups things like that. Faster than on-disk. 10. Look up the spec of yr usb3 connected device. Does it have 4k sectors? If it does, if you're using zfs make sure vfs.zfs.min_auto_ashift=12 in /etc/sysctl.conf 11. if you do compile stuff it'd be worth using -j3 if you want reasonably responsive interactive use from the pi while it's compiling. Like I've said, this isn't even guaranteed to work. All I can say is it's whats working on my rpi4/8GB now and I'm very happy with it. -- J. signature.asc Description: PGP signature
Re: possible usb3-connected hard drive spin down causing lag
Van: tech-lists Datum: vrijdag, 27 november 2020 04:24 Aan: freebsd-current@freebsd.org Onderwerp: Re: possible usb3-connected hard drive spin down causing lag Hi, It seems the issue wasn't with the hardware or the connection. I use mutt and it's the program that was slowing everything down, and that was down to me using new mutt with my old config. The whole pause for 5 seconds thing was due to it scanning gigabytes of email each time it woke up. The fix was to review the config and change a couple of settings. Now there's no delay (well there is a bit but only because it's scanning the folders it's told to for new mail). But looking at a hardware cause wasn't in vain. On the way to the solution, found a few tips through here that sped up the system generally, and learned a bit. So now I have a *really quick* raspberry pi4 which is rock-solid stable, so thanks :D -- J. Mind to share these tips, so I can use them on my RPI4? ;-) ___ 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"
Re: possible usb3-connected hard drive spin down causing lag
On Fri, 27 Nov 2020 07:34:32 +0100 Gary Jennejohn wrote: > On Thu, 26 Nov 2020 20:09:41 +0100 > Michael Gmelin wrote: > > > > On 26. Nov 2020, at 19:21, Gary Jennejohn wrote: > > > > > > ___On Thu, 26 Nov 2020 10:44:19 -0700 > > > Warner Losh wrote: > > > > > >>> On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin wrote: > > >>> > > >>> > > >>> > > >>> On Thu, 26 Nov 2020 10:12:06 +0100 > > >>> Gary Jennejohn wrote: > > >>> > > On Thu, 26 Nov 2020 01:14:02 -0700 > > Warner Losh wrote: > > > > > On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn > > > wrote: > > >> On Thu, 26 Nov 2020 00:10:40 + > > >> tech-lists wrote: > > >> > > >>> Hi, > > >>> > > >>> I have a usb3-connected harddrive. dmesg shows this: > > >>> [...] > > >>> da0: 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 Jen
Re: possible usb3-connected hard drive spin down causing lag
On Thu, 26 Nov 2020 20:09:41 +0100 Michael Gmelin wrote: > > On 26. Nov 2020, at 19:21, Gary Jennejohn wrote: > > > > ___On Thu, 26 Nov 2020 10:44:19 -0700 > > Warner Losh wrote: > > > >>> On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin wrote: > >>> > >>> > >>> > >>> On Thu, 26 Nov 2020 10:12:06 +0100 > >>> Gary Jennejohn wrote: > >>> > On Thu, 26 Nov 2020 01:14:02 -0700 > Warner Losh wrote: > > > On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn > > wrote: > >> On Thu, 26 Nov 2020 00:10:40 + > >> tech-lists wrote: > >> > >>> Hi, > >>> > >>> I have a usb3-connected harddrive. dmesg shows this: > >>> [...] > >>> da0: 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 ___ 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"
Re: possible usb3-connected hard drive spin down causing lag
On Thu, 26 Nov 2020 19:37:47 +0100 Dimitry Andric wrote: > On 26 Nov 2020, at 19:21, Gary Jennejohn wrote: > > > > On Thu, 26 Nov 2020 10:44:19 -0700 > > Warner Losh wrote: > ... > >>> 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. > > In this case it's about ATA commands being passed though the USB bridge. > Does "camcontrol identify daX" fail in your case too? > > I have used quite a bunch of different USB disks, mostly from WD or > Seagate, and these come with varying qualities of USB-SATA bridges in > them. But all of them work with "camcontrol identify". > camcontrol identify does work. The enclosure I tested has an ASMedia asm1153e bridge in it. This one idles the disk after a few minutes. -- 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"
Re: possible usb3-connected hard drive spin down causing lag
Hi, It seems the issue wasn't with the hardware or the connection. I use mutt and it's the program that was slowing everything down, and that was down to me using new mutt with my old config. The whole pause for 5 seconds thing was due to it scanning gigabytes of email each time it woke up. The fix was to review the config and change a couple of settings. Now there's no delay (well there is a bit but only because it's scanning the folders it's told to for new mail). But looking at a hardware cause wasn't in vain. On the way to the solution, found a few tips through here that sped up the system generally, and learned a bit. So now I have a *really quick* raspberry pi4 which is rock-solid stable, so thanks :D -- J. signature.asc Description: PGP signature
Re: possible usb3-connected hard drive spin down causing lag
On Thu, Nov 26, 2020 at 07:37:47PM +0100, Dimitry Andric wrote: In this case it's about ATA commands being passed though the USB bridge. Does "camcontrol identify daX" fail in your case too? I have used quite a bunch of different USB disks, mostly from WD or Seagate, and these come with varying qualities of USB-SATA bridges in them. But all of them work with "camcontrol identify". With my usb3 powered disk, camdontrol identify da0 works some features: support enabled value advanced power management yes yes 254/0xFE power management yes yes microcode download yes yes loads of others thanks for posting that script btw -- J. signature.asc Description: PGP signature
Re: possible usb3-connected hard drive spin down causing lag
> On 26. Nov 2020, at 19:21, Gary Jennejohn wrote: > > On Thu, 26 Nov 2020 10:44:19 -0700 > Warner Losh wrote: > >>> On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin wrote: >>> >>> >>> >>> On Thu, 26 Nov 2020 10:12:06 +0100 >>> Gary Jennejohn wrote: >>> On Thu, 26 Nov 2020 01:14:02 -0700 Warner Losh wrote: > On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn > wrote: >> On Thu, 26 Nov 2020 00:10:40 + >> tech-lists wrote: >> >>> Hi, >>> >>> I have a usb3-connected harddrive. dmesg shows this: >>> [...] >>> da0: 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ 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"
Re: possible usb3-connected hard drive spin down causing lag
On 26 Nov 2020, at 19:21, Gary Jennejohn wrote: > > On Thu, 26 Nov 2020 10:44:19 -0700 > Warner Losh wrote: ... >>> 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. In this case it's about ATA commands being passed though the USB bridge. Does "camcontrol identify daX" fail in your case too? I have used quite a bunch of different USB disks, mostly from WD or Seagate, and these come with varying qualities of USB-SATA bridges in them. But all of them work with "camcontrol identify". -Dimitry signature.asc Description: Message signed with OpenPGP
Re: possible usb3-connected hard drive spin down causing lag
On Thu, 26 Nov 2020 10:44:19 -0700 Warner Losh wrote: > On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin wrote: > > > > > > > On Thu, 26 Nov 2020 10:12:06 +0100 > > Gary Jennejohn wrote: > > > > > On Thu, 26 Nov 2020 01:14:02 -0700 > > > Warner Losh wrote: > > > > > > > On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn > > > > wrote: > > > > > On Thu, 26 Nov 2020 00:10:40 + > > > > > tech-lists wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I have a usb3-connected harddrive. dmesg shows this: > > > > > > [...] > > > > > > da0: 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. -- 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"
Re: possible usb3-connected hard drive spin down causing lag
On Thu, Nov 26, 2020 at 2:47 AM Dimitry Andric wrote: > On 26 Nov 2020, at 01:10, tech-lists wrote: > > > > I have a usb3-connected harddrive. dmesg shows this: > > [...] > > da0: 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 have been using the attached rc.d script for a long time now, which > uses camcontrol(8)'s "apm" and "aam" commands to set drives to 'maximum > performance' (aka don't try to save power by shutting down all the > time). > > Just drop this into /usr/local/etc/rc.d, and add something like the > following to your rc.conf: > > camperf_devices="da0 da1" > camperf_enable="YES" > > You can also manually start the rc.d script by running: > > sudo service camperf start > Should we have this, or a similar 'standby' setting as well in base? this question comes up a lot... Warner ___ 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"
Re: possible usb3-connected hard drive spin down causing lag
On Thu, Nov 26, 2020 at 4:16 AM Michael Gmelin wrote: > > > On Thu, 26 Nov 2020 10:12:06 +0100 > Gary Jennejohn wrote: > > > On Thu, 26 Nov 2020 01:14:02 -0700 > > Warner Losh wrote: > > > > > On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn > > > wrote: > > > > On Thu, 26 Nov 2020 00:10:40 + > > > > tech-lists wrote: > > > > > > > > > Hi, > > > > > > > > > > I have a usb3-connected harddrive. dmesg shows this: > > > > > [...] > > > > > da0: 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. Warner ___ 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"
Re: possible usb3-connected hard drive spin down causing lag
On Thu, 26 Nov 2020 10:12:06 +0100 Gary Jennejohn wrote: > On Thu, 26 Nov 2020 01:14:02 -0700 > Warner Losh wrote: > > > On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn > > wrote: > > > On Thu, 26 Nov 2020 00:10:40 + > > > tech-lists wrote: > > > > > > > Hi, > > > > > > > > I have a usb3-connected harddrive. dmesg shows this: > > > > [...] > > > > da0: 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 Best, Michael -- Michael Gmelin ___ 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"
Re: possible usb3-connected hard drive spin down causing lag
On 26 Nov 2020, at 01:10, tech-lists wrote: > > I have a usb3-connected harddrive. dmesg shows this: > [...] > da0: 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 have been using the attached rc.d script for a long time now, which uses camcontrol(8)'s "apm" and "aam" commands to set drives to 'maximum performance' (aka don't try to save power by shutting down all the time). Just drop this into /usr/local/etc/rc.d, and add something like the following to your rc.conf: camperf_devices="da0 da1" camperf_enable="YES" You can also manually start the rc.d script by running: sudo service camperf start -Dimitry camperf Description: Binary data signature.asc Description: Message signed with OpenPGP
Re: possible usb3-connected hard drive spin down causing lag
On Thu, 26 Nov 2020 01:14:02 -0700 Warner Losh wrote: > On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn wrote: > > > On Thu, 26 Nov 2020 00:10:40 + > > tech-lists wrote: > > > > > Hi, > > > > > > I have a usb3-connected harddrive. dmesg shows this: > > > [...] > > > da0: 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. -- 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"
Re: possible usb3-connected hard drive spin down causing lag
On Thu, Nov 26, 2020 at 1:07 AM Gary Jennejohn wrote: > On Thu, 26 Nov 2020 00:10:40 + > tech-lists wrote: > > > Hi, > > > > I have a usb3-connected harddrive. dmesg shows this: > > [...] > > da0: 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. Warner ___ 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"
Re: possible usb3-connected hard drive spin down causing lag
On Thu, 26 Nov 2020 00:10:40 + tech-lists wrote: > Hi, > > I have a usb3-connected harddrive. dmesg shows this: > [...] > da0: 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. -- 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"
possible usb3-connected hard drive spin down causing lag
Hi, I have a usb3-connected harddrive. dmesg shows this: [...] da0: 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, -- J. signature.asc Description: PGP signature
