Re: Upgrading to current prep
On Mon, 12 Mar 2018 22:34:44 +1100 > I keep hearing about longevity issues with flash based storage. It > seems this paranoia just won't die. > It is not paranoia but dependent on use cases! The OPs concerns have a high chance to be unfounded however. > I'm coming up to 13 years of installing OpenBSD onto flash based > storage and I've not had a failure yet. That isn't surprising. If you take the lowest power flash with the worst guarantee of 10,000 writes as oppose to the 100,000 write flash then even with KARL that would allow 27 years of daily boots, right. Scratch/swap space is rarely used with the memory available in modern systems too. That is also assuming the same sectors are written each time. Also, cheap onboard or flash sticks are very different to SSD with built in write management and space reservation. High write use cases could be an issue however, perhaps sql databases and partition table updates are an issue? Additionally I have had adoptable sd on Android have a weird failure where I couldn't wipe or write anything new but could always read the data back atleast after a replug so it is possible that you may not always detect failures. I don't use adoptable SD on Android any more despite wanting to. I assume but I am not sure how SDs differ to onboard phone memory though or the management differs for the experimental feature or perhaps it was just an odd hw failure where sw thought the writes had occurred but they had not physically?
Re: Upgrading to current prep
On Mon, Mar 12, 2018 at 10:34:44PM +1100, SJP Lists wrote: > > On Sat, Mar 10, 2018 at 11:42:55PM -0500, Rupert Gallagher wrote: > > > > > only as originally intended for unix systems. Further, variable > > > content partitions such as /var and /home should be large enough to > > > allow for ssd wear levelling, or you will toss away expensive ssds > > > like autumn leaves. Finally, all games should be moved from the > > I keep hearing about longevity issues with flash based storage. It seems > this paranoia just won't die. > > I'm coming up to 13 years of installing OpenBSD onto flash based storage > and I've not had a failure yet. Only ever used softdep and noatime. > Installed into Sun Ultra's with IDE-CD adaptors, Soekris 5501 and 6501, > ALIX 2's and 3's and now also running off thumb drives in these sweet > little EdgeRouter LITE's. Always stuck to SanDisk and Lexar. > > https://marc.info/?l=openbsd-misc=113148165022620=2 > > I had one 2.5" Corsair SSD fail outside of OpenBSD usage, but it was a > sudden death and well within the infant mortality stage of the bathtub > curve. > > And on a note related to SSD longevity, I've run Samsung SSD's in my > Sony PS4 and PS4 Pro since both were released and they both constantly > write video capture data to "disk" while on and this is a feature I > cannot switch off. They're both still working fine too. My PS4 would > have hammered that SSD for hours most days for about 4 years. > > > Shane I have more or less the same experience. I always allocate some unused partition on my ssd's, about 10%. But I do not have any data if that is having anything to do with the good experience I have with ssd's. -Otto
Re: Upgrading to current prep
> On Sat, Mar 10, 2018 at 11:42:55PM -0500, Rupert Gallagher wrote: > > > only as originally intended for unix systems. Further, variable > > content partitions such as /var and /home should be large enough to > > allow for ssd wear levelling, or you will toss away expensive ssds > > like autumn leaves. Finally, all games should be moved from the I keep hearing about longevity issues with flash based storage. It seems this paranoia just won't die. I'm coming up to 13 years of installing OpenBSD onto flash based storage and I've not had a failure yet. Only ever used softdep and noatime. Installed into Sun Ultra's with IDE-CD adaptors, Soekris 5501 and 6501, ALIX 2's and 3's and now also running off thumb drives in these sweet little EdgeRouter LITE's. Always stuck to SanDisk and Lexar. https://marc.info/?l=openbsd-misc=113148165022620=2 I had one 2.5" Corsair SSD fail outside of OpenBSD usage, but it was a sudden death and well within the infant mortality stage of the bathtub curve. And on a note related to SSD longevity, I've run Samsung SSD's in my Sony PS4 and PS4 Pro since both were released and they both constantly write video capture data to "disk" while on and this is a feature I cannot switch off. They're both still working fine too. My PS4 would have hammered that SSD for hours most days for about 4 years. Shane
Re: Upgrading to current prep
On Sun, Mar 11, 2018 at 11:00:06AM +, Mihai Popescu wrote: > > ... should be ... > > Why are some people considering OpenBSD should suit them and only them? > They are not even part from development project, they are not even > close to the concept and still proclaiming on the mail list what > "should be". I always wonder where this feeling of better knowledge > comes from. > Learn what you want to use your system for. I use two different disklabels, one for a system that is strictly for Desktop with no space wasted on development partitions. The second uses partitions for development. For example, /usr/ports /usr/distfiles /usr/packages /usr/pobj. Since I always use the webserver, if I want to do work with that also, I add /var/www as a partition. I do not add a /home partition, but just add a home folder to some other partition in order to gain another development partition. You usually need a non-root user for testing. You can set a configuration to make the /home just something like /var/home. You should be learning more first. Get a few USB sticks to boot off of and start playing around and read the FAQ and man pages about the .conf files. Best way to learn is to really screw the pooch and then find out why. We all did that at one time. It takes some time to learn OpenBSD and it keeps moving forward constantly changing. Note that that usually means getting MUCH better and MORE secure. Have a little fun. And you will find a piece of documentation that says, first panic, you're going to do that anyway. :) Chris Bennett
Re: Upgrading to current prep
> ... should be ... Why are some people considering OpenBSD should suit them and only them? They are not even part from development project, they are not even close to the concept and still proclaiming on the mail list what "should be". I always wonder where this feeling of better knowledge comes from.
Re: Upgrading to current prep
On Sun, Mar 11, 2018 at 11:27:19AM +0100, Otto Moerbeek wrote: > On Sun, Mar 11, 2018 at 04:04:29AM -0400, Rupert Gallagher wrote: > > > > The default setup and autoallocation fits development use, for that > > /usr shoud be modifiable. > > > > It can be remounted rw in that case. No need to keep it rw by default with > > src and obj inside. The unix standard ro is more secure. > > > > > If the default sizes do not fit you, you can modify them interactively > > after auto allocation using the R command or by using an alternate > > auto allocation table. > > > > I do not want the installer to fall back to the shell. I need a custom A > > option. > > The installer *asks* if you weant to modify the auto-allocated one. NO > need to fall back to shell. Also using an alternate table is possible. > If you do not want to learn about the tools available, that's your > problem. > > -Otto I'll explain it differently. As developers we have the (earned) privilege to come up with the default behaviour of the installer. That's a compromise already, but geared towards a development system. We realize the defaults are not suitable for everyone. So we've added mechanisms to adapt the default behaviour of the installer. But if you come here to bitch about default behaviour and you show you didn't study the mechanisms to change it, what can we do? -Otto
Re: Upgrading to current prep
On Sun, Mar 11, 2018 at 04:04:29AM -0400, Rupert Gallagher wrote: > > The default setup and autoallocation fits development use, for that > /usr shoud be modifiable. > > It can be remounted rw in that case. No need to keep it rw by default with > src and obj inside. The unix standard ro is more secure. > > > If the default sizes do not fit you, you can modify them interactively > after auto allocation using the R command or by using an alternate > auto allocation table. > > I do not want the installer to fall back to the shell. I need a custom A > option. The installer *asks* if you weant to modify the auto-allocated one. NO need to fall back to shell. Also using an alternate table is possible. If you do not want to learn about the tools available, that's your problem. -Otto
Re: Upgrading to current prep
On Sat, Mar 10, 2018 at 11:42:55PM -0500, Rupert Gallagher wrote: > Obsd default partitioning and default packaging still fails me. > /usr/src and /usr/obj contain variable content, and thus should be > /var/src and /var/obj instead, allowing for /usr to be mounted read > only as originally intended for unix systems. Further, variable > content partitions such as /var and /home should be large enough to > allow for ssd wear levelling, or you will toss away expensive ssds > like autumn leaves. Finally, all games should be moved from the > default packages to ports. These changes are done systematically here, > and it is swearing and smothering each time we do it. > > Sent from > ProtonMail Mobile > > > ,> ,> ,> Get a decent mailer that wraps lines. The default setup and autoallocation fits development use, for that /usr shoud be modifiable. If the default sizes do not fit you, you can modify them interactively after auto allocation using the R command or by using an alternate auto allocation table. As for wear levelling, it is enough to not just allocate part of the ssd. It does not not matter if that part is in an fs or not. Actually, it might be better to make the free space not part of an fs. As for the games, they have always been part of OpenBSD. -Otto
Re: Upgrading to current prep
On Sat, Mar 10, 2018 at 07:22:43PM +, Otto Moerbeek wrote: > On Sat, Mar 10, 2018 at 02:15:02PM -0500, math...@posteo.net wrote: > > > > You would not be the first > > > one to have written to a file in /dev instead of a device. > > > > Thats exactly what happened, my /dev/sd1 is 943056 bytes large > > I was trying to dd dragonflybsd to a usb stick earlier this week and messed > > up. > > > > What exactly do I have to do to fix this? > > just rm the file. /dev/sd1 is not a device name anyway, > > -Otto cool, thanks!
Re: Upgrading to current prep
On Sat, Mar 10, 2018 at 01:43:04PM -0500, math...@posteo.net wrote: > Hi folks, > I'm upgrading to -current today, but before I did that I've been > backuping stuff and making sure I understand the current state of my > system. My system runs 6.2-release with all syspatches. > > When I installed the system I used the basic installation settings and > did not modify much, for instance I let openbsd partition the drive. > > The main weird thing I noticed this morning was after running df. > > Filesystem SizeUsed Avail Capacity Mounted on > /dev/sd0a 1005M995M -40.8M 104%/ > /dev/sd0k 184G 14.6G160G 8%/home > /dev/sd0d 3.9G3.4M3.7G 0%/tmp > /dev/sd0f 2.0G1.1G810M58%/usr > /dev/sd0g 1005M178M777M19%/usr/X11R6 > /dev/sd0h 9.8G4.8G4.5G52%/usr/local > /dev/sd0j 5.9G2.0K5.6G 0%/usr/obj > /dev/sd0i 2.0G2.0K1.9G 0%/usr/src > /dev/sd0e 19.0G 90.9M 18.0G 0%/var > > I'm not sure what happened here, but it may be that the default space > allocation for / space is too small for desktop usage? It's more > probable that I've just messed up somehow. Worse case scenario I'm not > against rebooting into a snapshot bsd.rd and repartioning myself, I just > backed up everything of import anyways. 1005M of / is large enoug for almost all cases. It is more likely you wrote something into /. Try finding it with cd / ; du -kx | sort -n and then zooming into the large dir. You would not be the first one to have written to a file in /dev instead of a device. -Otto > > Dmesg just for good measure: > OpenBSD 6.2 (GENERIC.MP) #6: Wed Feb 28 21:13:02 CET 2018 > > r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8261529600 (7878MB) > avail mem = 8004075520 (7633MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) > bios0: vendor LENOVO version "N14ET42W (1.20 )" date 09/13/2017 > bios0: LENOVO 20BTS0Y500 > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT > SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpiec0 at acpi0 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2594.51 MHz > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: TSC frequency 2594513870 Hz > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2594.00 MHz > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2594.00 MHz > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 1, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2594.00 MHz > cpu3: >
Upgrading to current prep
Hi folks, I'm upgrading to -current today, but before I did that I've been backuping stuff and making sure I understand the current state of my system. My system runs 6.2-release with all syspatches. When I installed the system I used the basic installation settings and did not modify much, for instance I let openbsd partition the drive. The main weird thing I noticed this morning was after running df. Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0a 1005M995M -40.8M 104%/ /dev/sd0k 184G 14.6G160G 8%/home /dev/sd0d 3.9G3.4M3.7G 0%/tmp /dev/sd0f 2.0G1.1G810M58%/usr /dev/sd0g 1005M178M777M19%/usr/X11R6 /dev/sd0h 9.8G4.8G4.5G52%/usr/local /dev/sd0j 5.9G2.0K5.6G 0%/usr/obj /dev/sd0i 2.0G2.0K1.9G 0%/usr/src /dev/sd0e 19.0G 90.9M 18.0G 0%/var I'm not sure what happened here, but it may be that the default space allocation for / space is too small for desktop usage? It's more probable that I've just messed up somehow. Worse case scenario I'm not against rebooting into a snapshot bsd.rd and repartioning myself, I just backed up everything of import anyways. Dmesg just for good measure: OpenBSD 6.2 (GENERIC.MP) #6: Wed Feb 28 21:13:02 CET 2018 r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8261529600 (7878MB) avail mem = 8004075520 (7633MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) bios0: vendor LENOVO version "N14ET42W (1.20 )" date 09/13/2017 bios0: LENOVO 20BTS0Y500 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2594.51 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2594513870 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2594.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2594.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2594.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 3 (EXP1) acpiprt3 at acpi0: bus 4 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 10 (EXP6) acpicpu0
