On Mon, Sep 28, 2020 at 08:25:34AM -0600, Theo de Raadt wrote:
> ...
> So we are at an impasse. The recommended solution is for people to stop
> making sysupgrade-incompatible layouts in the future, and to consider
> repairing their incompatible layouts from the past.
>
> if sysupgrade doesn't work, people have the old ways of doing things.
> doctor doctor it hurts when i layout my disk strangely...
Hi there,
So, I think I have a workaround for my issue with sysupgrade and, from my
side, everything is more or less hunky dory ... but as Theo wrote, now I
have in the back of my mind "consider repairing" ...
So I just have to ask ... what then would be the supported/approved disk
layout for OpenBSD 6.8 on my Intel 8i5 NUC with the following storage:
1. A 2TB Samsung SSD: Currently identified as:
sd0 at scsibus1 targ 2 lun 0: <ATA, Samsung SSD 860, RVM0> naa.5002538e4109632a
sd0: 1953514MB, 512 bytes/sector, 4000797360 sectors, thin
2. A 512GB Samsung M.2 NVMe device: Currently identified as:
sd1 at scsibus2 targ 1 lun 0: <NVMe, Samsung SSD 970, 1B2Q>
sd1: 476940MB, 512 bytes/sector, 976773168 sectors
It's my main desktop system, running XFCE.
Currently df shows:
Filesystem Size Used Avail Capacity Mounted on
/dev/sd1a 1005M 314M 640M 33% /
mfs:6361 7.7G 331M 7.0G 4% /tmp
/dev/sd1e 58.3G 91.3M 55.3G 0% /var
/dev/sd1f 2.0G 1.2G 686M 64% /usr
/dev/sd1g 1005M 251M 703M 26% /usr/X11R6
/dev/sd1h 19.7G 11.0G 7.7G 59% /usr/local
/dev/sd1k 5.9G 2.0K 5.6G 0% /usr/obj
/dev/sd1j 2.0G 2.0K 1.9G 0% /usr/src
/dev/sd1l 295G 10.0G 271G 4% /fast
/dev/sd0h 1.8T 964G 758G 56% /space
(Yeah, yeah, when I installed I made "/var" way too big for some reason.)
There is a swap area on sd1b of 64GB (twice the size of the RAM). At
install time I thought about not allocating any swap at all, but I wasn't
sure if that was a good idea or not.
That mount "/space" contains essentially all the non OS stuff in
subdirectories e.g. "home", "images", "videos", "music", "netapp". It
will eventually be just over 1TB (and then keep growing :). Too big to
fit on the NVMe stick.
The "/fast" mount is used for working/output data from apps e.g.
Wireshark, Influxdb, Telegraf, Grafana, NetApp.
How would 6.8 layout these drives differently. if I were to installed it,
from scratch, for example?
Output of disklabel below.
Feel free to ignore this email, since, if I am honest, I am unlikely to
start moving >1TB of data around for fun (maybe with the next hardware
refresh). But I would still be interested to hear how it would be done
differently.
Cheers,
Robb.
disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Samsung SSD 860
duid: 7a1775fef773535e
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 249038
total sectors: 4000797360
boundstart: 64
boundend: 4000797297
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 2097152 1024 4.2BSD 2048 16384 12958
c: 4000797360 0 unused
h: 3998699008 2098176 4.2BSD 8192 65536 52270 # /space
disklabel sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: Samsung SSD 970
duid: 281ef747da03afe7
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 60801
total sectors: 976773168
boundstart: 1024
boundend: 976773105
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 2097152 1024 4.2BSD 2048 16384 12958 # /
b: 67324128 2098176 swap # none
c: 976773168 0 unused
d: 8388608 69422304 4.2BSD 2048 16384 12958
e: 124326848 77810912 4.2BSD 2048 16384 12958 # /var
f: 4194304 202137760 4.2BSD 2048 16384 12958 # /usr
g: 2097152 206332064 4.2BSD 2048 16384 12958 # /usr/X11R6
h: 41943040 208429216 4.2BSD 2048 16384 12958 # /usr/local
i: 960 64 MSDOS
j: 4194304 250372256 4.2BSD 2048 16384 12958 # /usr/src
k: 12582912 254566560 4.2BSD 2048 16384 12958 # /usr/obj
l: 629145536 267149504 4.2BSD 4096 32768 26062 # /fast
No comments:
Post a Comment