On 2020/09/29 14:25, Why 42? The lists account. wrote:
>
> 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
MFS isn't particularly quick, you might well find one or other of your
SSDs is faster.
> /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.
AIUI it is a bad idea to have no swap. 2xRAM is good if you have a
possible use for kernel crashdumps but that'll take a fair old time on
a 32G system and often doesn't work anyway, I'll usually go for 4-8G or
so.
> 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.
Given what you have shown I would probably just rename /space to /home
(and maybe add a /space -> /home symlink if there is much software
using that path, to avoid tracking it all down to change it).
Example commands
boot> boot -s
...
# fsck -p
# mount -a
# umount /space
# mv space home
# sed -i s,space,home, /etc/fstab
# ln -s home space
# mount /home
# ^D
> 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?
You can see what disklabel auto defaults would be with e.g. "disklabel
-A -n sd0" (-n tells it not to write). I rarely use defaults myself
except by mistake though, they are unsuitable for machines doing
ports development, and often unsuitable for servers, though they
aren't too bad for workstations.
> 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