Re: What's changing the default route?
On Sun, Jul 02, 2017 at 08:27:36AM +, Stuart Henderson wrote: > On 2017-07-01, Claudio Jeker wrote: > > On Sat, Jul 01, 2017 at 04:48:05PM +0200, tonypon...@mail.com wrote: > >> I use an ssh tunnel for a VPN on OpenBSD 6.1. To initiate the VPN > >> connection, I type the following on the local machine > >> > >> # ssh -f -w 0:1 R true > >> # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 > >> # route add R G > >> # route change default 10.1.1.2 > >> > >> where R is the IP address of the remote server, and where G is the IP > >> address of the local gateway. > >> > >> Usually, this works well. But I occasionally have a problem where the > >> default address in the routing table will spontaneously change from > >> 10.1.1.2 to G. What could be causing the routing table to spontaneously > >> change in this manner without my intervention? > >> > > > > Most probably dhclient(8). > > A hackish workaround to this would be to add routes for 0.0.0.0/1 > and 128.0.0.0/1 instead of changing the default route. > Or even better use the -priority and add it with a lower prio (e.g. 2). -- :wq Claudio
Re: ext2 or usb problem
On Sun, Jul 02, 2017 at 01:51:48PM -0400, Donald Allen wrote: > On 1 July 2017 at 18:55, Juan Francisco Cantero Hurtado > wrote: > > On Sat, Jul 01, 2017 at 03:43:48PM -0400, Donald Allen wrote: > >> On 1 July 2017 at 12:06, Juan Francisco Cantero Hurtado > >> wrote: > >> > >> > The USB disks and ext2 are both quite slow on OpenBSD. Try with FFS but > >> > you're not going to see better numbers. > >> > > >> > On Linux, the kernel uses UAS for your USB disks. We only supports > >> > bulk-only. > >> > >> If you are implying that if I had only waited a week or a month for > >> this to complete on OpenBSD yesterday, I think you are incorrect. This > >> was hung, not slow. > > > > No, it's just slow. I've had the same problem for years. Our ext2 > > implementation is slow even on SATA. > > This is not helpful. You insist that you know what is going on when I > was in front of the computer and you were not. File copying to an ext2 > filesystem on a usb drive is 10x slower than to an ffs filesystem on > an internal sata drive mounted async (ext2 is async; apples to > apples). I know because I've measured it, including the time to sync. > The file in question was 1.5 GB. That copy should have taken 150 > seconds or so at the rates I measured. The system sat there for two > hours, as I said in my message. And when I came back, it was making no > progress, as I also said in my message. I'm done discussing this. I've > reported what I found and offered to help debug it. My workaround is > simple: I will do these backup disk updates and anything else > involving ext2/usb disks with Linux. You're taking my comments too personally. I was talking only from my experience. You can't mount ext2 with "async" on OpenBSD. FFS only syncs the metadata by default, that's why the "sync" option exists for FFS. And you can't compare a SATA disks with an USB bulk-only. So, you're not comparing apples to apples. I've copied a file to an USB disk formatted as ext2 and the speed is about 12MB/s. It's similar to your numbers with the 1.5GB file. My point was that if you're writing a lot of metadata updates (something usual with rsync), due to the limitations of our ext2 implementation and the USB stack, the process sometimes will get stuck. Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
ahci port multiplexer on armv7
All, I've found a relatively cheap multi-disk chassis that connects using e-SATA. Since my machine doesn't have e-SATA, I've ordered a simple e-SATA card which is currently on backorder. However, I realized my Cubox has an e-SATA port, so I tried connecting it there, and it does get detected. However, with errors and the disks that are in the chassis are not found: imxahci0 at simplebus0: AHCI 1.3 imxahci0: port multiplier found: chip=38261095 rev=0x1706 nports=6, features: 0x9, enabled: 0x1 imxahci0: device on port 0 didn't come ready, TFD: 0x50 imxahci0: port 0: 3.0Gb/s scsibus0 at imxahci0: 32 targets uk0 at scsibus0 targ 0 lun 0: SCSI3 30/unknown fixed imxahci0.0: unable to clear PHY status imxahci0.0: PMP port softreset cmd failed imxahci0.0: unable to clear PHY status imxahci0.0: PMP port softreset cmd failed imxahci0.0: unable to probe PMP port due to softreset failure imxahci0.1: unable to probe PMP port; portreset failed imxahci0.2: unable to probe PMP port; portreset failed imxahci0.3: unable to probe PMP port; portreset failed imxahci0.4: unable to probe PMP port; portreset failed imxahci0.5: unable to probe PMP port; portreset failed I have no prior experience with port multipliers on OpenBSD, so I'm not sure where the problem lies. Is this a limitation of imxahci? Cheers, Paul 'WEiRD' de Weerd OpenBSD 6.1-current (GENERIC) #193: Sat Jul 1 03:40:04 MDT 2017 dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/GENERIC real mem = 2147483648 (2048MB) avail mem = 2097532928 (2000MB) mainbus0 at root: SolidRun Cubox-i Dual/Quad cpu0 at mainbus0: ARM Cortex A9 R2 rev 10 (ARMv7 core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(32b/l,4way) I-cache, 32KB(32b/l,4way) wr-back D-cache cortex0 at mainbus0 amptimer0 at cortex0: tick rate 396000 KHz armliicc0 at cortex0: rtl 7 waymask: 0x000f simplebus0 at mainbus0: "soc" ampintc0 at simplebus0 nirq 160, ncpu 4 simplebus1 at simplebus0: "aips-bus" imxccm0 at simplebus1: imx6 rev 1.5 CPU freq: 792 MHz imxiomuxc0 at simplebus1 simplebus2 at simplebus1: "spba-bus" imxuart0 at simplebus2: console imxgpio0 at simplebus1 imxgpio1 at simplebus1 imxgpio2 at simplebus1 imxgpio3 at simplebus1 imxgpio4 at simplebus1 imxgpio5 at simplebus1 imxgpio6 at simplebus1 imxdog0 at simplebus1 imxtemp0 at simplebus1 imxgpc0 at simplebus1 simplebus3 at simplebus0: "aips-bus" imxehci0 at simplebus3 usb0 at imxehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "i.MX6 EHCI root hub" rev 2.00/1.00 addr 1 imxehci1 at simplebus3 usb1 at imxehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "i.MX6 EHCI root hub" rev 2.00/1.00 addr 1 fec0 at simplebus3 fec0: address d0:63:b4:00:3f:fb atphy0 at fec0 phy 0: AR8035 10/100/1000 PHY, rev. 2 imxesdhc0 at simplebus3 imxesdhc0: 198 MHz base clock sdmmc0 at imxesdhc0: 4-bit, mmc high-speed, dma imxesdhc1 at simplebus3 imxesdhc1: 198 MHz base clock sdmmc1 at imxesdhc1: 4-bit, mmc high-speed, dma imxiic0 at simplebus3 iic0 at imxiic0 imxiic1 at simplebus3 iic1 at imxiic1 pcfrtc0 at iic1 addr 0x68: battery ok imxocotp0 at simplebus3 imxuart1 at simplebus3 imxahci0 at simplebus0: AHCI 1.3 imxahci0: port multiplier found: chip=38261095 rev=0x1706 nports=6, features: 0x9, enabled: 0x1 imxahci0: device on port 0 didn't come ready, TFD: 0x50 imxahci0: port 0: 3.0Gb/s scsibus0 at imxahci0: 32 targets uk0 at scsibus0 targ 0 lun 0: SCSI3 30/unknown fixed imxahci0.0: unable to clear PHY status imxahci0.0: PMP port softreset cmd failed imxahci0.0: unable to clear PHY status imxahci0.0: PMP port softreset cmd failed imxahci0.0: unable to probe PMP port due to softreset failure imxahci0.1: unable to probe PMP port; portreset failed imxahci0.2: unable to probe PMP port; portreset failed imxahci0.3: unable to probe PMP port; portreset failed imxahci0.4: unable to probe PMP port; portreset failed imxahci0.5: unable to probe PMP port; portreset failed simplebus4 at mainbus0: "regulators" scsibus1 at sdmmc1: 2 targets, initiator 0 sd0 at scsibus1 targ 1 lun 0: SCSI2 0/direct removable sd0: 14772MB, 512 bytes/sector, 30253056 sectors (manufacturer 0x2d0, product 0x4330)at sdmmc0 function 1 not configured (manufacturer 0x2d0, product 0x4330)at sdmmc0 function 2 not configured vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets boot device: sd0 root on sd0a (fe2f3d685a24e68d.a) swap on sd0b dump on sd0b -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: ext2 or usb problem
On 2 July 2017 at 14:02, Theo de Raadt wrote: >> On 2 July 2017 at 13:54, Theo de Raadt wrote: >> >> This is not helpful. You insist that you know what is going on when I >> >> was in front of the computer and you were not. File copying to an ext2 >> >> filesystem on a usb drive is 10x slower than to an ffs filesystem on >> >> an internal sata drive mounted async (ext2 is async; apples to >> >> apples). I know because I've measured it, including the time to sync. >> >> The file in question was 1.5 GB. That copy should have taken 150 >> >> seconds or so at the rates I measured. The system sat there for two >> >> hours, as I said in my message. And when I came back, it was making no >> >> progress, as I also said in my message. I'm done discussing this. I've >> >> reported what I found and offered to help debug it. My workaround is >> >> simple: I will do these backup disk updates and anything else >> >> involving ext2/usb disks with Linux. >> > >> > Then why all the angst? >> > >> > If you really wanted it fixed you have the src code. Yelling at people >> > isn't helpful either, is it? >> >> If you consider this 'yelling', then you really need to consult a >> dictionary. And you are a fine one to be lecturing anyone about >> yelling. > > Look, you don't get to lecture developers who are trying to help. > > Please leave here. Done.
Re: ext2 or usb problem
> On 2 July 2017 at 13:54, Theo de Raadt wrote: > >> This is not helpful. You insist that you know what is going on when I > >> was in front of the computer and you were not. File copying to an ext2 > >> filesystem on a usb drive is 10x slower than to an ffs filesystem on > >> an internal sata drive mounted async (ext2 is async; apples to > >> apples). I know because I've measured it, including the time to sync. > >> The file in question was 1.5 GB. That copy should have taken 150 > >> seconds or so at the rates I measured. The system sat there for two > >> hours, as I said in my message. And when I came back, it was making no > >> progress, as I also said in my message. I'm done discussing this. I've > >> reported what I found and offered to help debug it. My workaround is > >> simple: I will do these backup disk updates and anything else > >> involving ext2/usb disks with Linux. > > > > Then why all the angst? > > > > If you really wanted it fixed you have the src code. Yelling at people > > isn't helpful either, is it? > > If you consider this 'yelling', then you really need to consult a > dictionary. And you are a fine one to be lecturing anyone about > yelling. Look, you don't get to lecture developers who are trying to help. Please leave here.
Re: ext2 or usb problem
On 2 July 2017 at 13:54, Theo de Raadt wrote: >> This is not helpful. You insist that you know what is going on when I >> was in front of the computer and you were not. File copying to an ext2 >> filesystem on a usb drive is 10x slower than to an ffs filesystem on >> an internal sata drive mounted async (ext2 is async; apples to >> apples). I know because I've measured it, including the time to sync. >> The file in question was 1.5 GB. That copy should have taken 150 >> seconds or so at the rates I measured. The system sat there for two >> hours, as I said in my message. And when I came back, it was making no >> progress, as I also said in my message. I'm done discussing this. I've >> reported what I found and offered to help debug it. My workaround is >> simple: I will do these backup disk updates and anything else >> involving ext2/usb disks with Linux. > > Then why all the angst? > > If you really wanted it fixed you have the src code. Yelling at people > isn't helpful either, is it? If you consider this 'yelling', then you really need to consult a dictionary. And you are a fine one to be lecturing anyone about yelling.
Re: ext2 or usb problem
> This is not helpful. You insist that you know what is going on when I > was in front of the computer and you were not. File copying to an ext2 > filesystem on a usb drive is 10x slower than to an ffs filesystem on > an internal sata drive mounted async (ext2 is async; apples to > apples). I know because I've measured it, including the time to sync. > The file in question was 1.5 GB. That copy should have taken 150 > seconds or so at the rates I measured. The system sat there for two > hours, as I said in my message. And when I came back, it was making no > progress, as I also said in my message. I'm done discussing this. I've > reported what I found and offered to help debug it. My workaround is > simple: I will do these backup disk updates and anything else > involving ext2/usb disks with Linux. Then why all the angst? If you really wanted it fixed you have the src code. Yelling at people isn't helpful either, is it?
Re: ext2 or usb problem
On 1 July 2017 at 18:55, Juan Francisco Cantero Hurtado wrote: > On Sat, Jul 01, 2017 at 03:43:48PM -0400, Donald Allen wrote: >> On 1 July 2017 at 12:06, Juan Francisco Cantero Hurtado >> wrote: >> >> > The USB disks and ext2 are both quite slow on OpenBSD. Try with FFS but >> > you're not going to see better numbers. >> > >> > On Linux, the kernel uses UAS for your USB disks. We only supports >> > bulk-only. >> >> If you are implying that if I had only waited a week or a month for >> this to complete on OpenBSD yesterday, I think you are incorrect. This >> was hung, not slow. > > No, it's just slow. I've had the same problem for years. Our ext2 > implementation is slow even on SATA. This is not helpful. You insist that you know what is going on when I was in front of the computer and you were not. File copying to an ext2 filesystem on a usb drive is 10x slower than to an ffs filesystem on an internal sata drive mounted async (ext2 is async; apples to apples). I know because I've measured it, including the time to sync. The file in question was 1.5 GB. That copy should have taken 150 seconds or so at the rates I measured. The system sat there for two hours, as I said in my message. And when I came back, it was making no progress, as I also said in my message. I'm done discussing this. I've reported what I found and offered to help debug it. My workaround is simple: I will do these backup disk updates and anything else involving ext2/usb disks with Linux.
Re: What's changing the default route?
On 2017-07-01, Claudio Jeker wrote: > On Sat, Jul 01, 2017 at 04:48:05PM +0200, tonypon...@mail.com wrote: >> I use an ssh tunnel for a VPN on OpenBSD 6.1. To initiate the VPN >> connection, I type the following on the local machine >> >> # ssh -f -w 0:1 R true >> # ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252 >> # route add R G >> # route change default 10.1.1.2 >> >> where R is the IP address of the remote server, and where G is the IP >> address of the local gateway. >> >> Usually, this works well. But I occasionally have a problem where the >> default address in the routing table will spontaneously change from >> 10.1.1.2 to G. What could be causing the routing table to spontaneously >> change in this manner without my intervention? >> > > Most probably dhclient(8). A hackish workaround to this would be to add routes for 0.0.0.0/1 and 128.0.0.0/1 instead of changing the default route.
