[nix23]

My biggest problem with OpenBSD is the partitioning, do i want security? Then i need partitions with w^x but how big should they be without wasting to much space. I think OpenBSD would greatly benefit from stuff like zfs-filesystems or btrfs sub-partitions...and NO i don't say OpenBSD needs ZFS, just a more flexible partition mechanism, maybe overlay with quota or something?

[mrweasel]

Having used OpenBSD and seeing how partitions and mount options are used to increase security, it’s really weird going back to a Linux system where everything is just one big partition.

You’re right though, it’s really tricky getting the partition sizes right. The auto layout is sensible, I just feel that it set aside to much space for home and to little for var.

Linux has all the tools to make use of partitions, but many distros still just go for one big partition. It seems counter intuitive.

[xorcist]

It's a relatively recent thing. Before that, all major Linux distributions gave you a bunch of different filesystems by default. Which is how all UNIX-like systems worked, for a number of historical reasons.

This wasn't great in practice. One partition layout certainly doesn't fit everbody, and there is a world of difference between the use case of a laptop, a database server, and a small web server. Most people outgrew the default setup rather quickly.

Over time installers tended to get the simplest use case as default, while allowing users with knowledge to choose their desired file system setup.

Since more than a decade ago it's not necessary to choose since all major file systems have online resizing capabilities and you can change the setup without downtime. There's also no need to be limited by the age old partitioning format. That made the simple default even more appropriate.

[anthk]

BSD's don't use partitions, but slices.

And, well, NetBSD it's pretty conservative, but OpenBSD's defaults are good for a desktop.

[foxfluff]

What distinction are you trying to make?

     The disklabel utility can be used to install, examine, or modify the
     label on a disk drive or pack.  The disk label contains information about
     disk characteristics (size, type, etc.) and the partition layout, stored
     on the disk itself.

     disklabel supports 15 configurable partitions, `a' through `p', excluding
     `c'.  The `c' partition describes the entire physical disk, is
     automatically created by the kernel, and cannot be modified or deleted by
     disklabel.  By convention, the `a' partition of the boot disk is the root
     partition, and the `b' partition of the boot disk is the swap partition,
     but all other letters can be used in any order for any other partitions
     as desired.

The word "slice" does not come up in disklabel's man page at all.

http://man.openbsd.org/disklabel

[rjsw]

How about "The other BSDs use slices".

FreeBSD [1] and NetBSD[2] can use GUID partition tables as well as traditional BSD disk labels.

[1] https://www.freebsd.org/cgi/man.cgi?query=gdisk&apropos=0&se... [2] https://man.netbsd.org/gpt.8

[trasz]

At least in case of FreeBSD, it’s more “uses GPT by default” than “can use”.

[anthk]

Your openbsd sd0e partition wont show up under fdisk. sd0c will as it can be maped to either the openbsd A6 partition under MBR/GPT or a disklabel using the whole disk.

[foxfluff]

As far as I know the c partition is always the whole disk, regardless of what you have (or don't have) in MBR or GPT. If you want to image the whole disk with dd, you'll reach for rsd0c, always.

But I still don't understand what distinction you're trying to make. Yes, disklabel partitions don't show up in MRB, just as GPT partitions won't. No surprise that the three different partitioning methods aren't exactly aware of each other.

[tremon]

For all practical intents and purposes, BSD's use partitions. They just call them differently because they use a different technical implementation. But they're still just as static and just as limiting as regular partitions.

[MobiusHorizons]

The important distinction for me is that the tools for working with partitions exist on openBSD (eg fdisk) but those deal with mbr/ gpt partitions, and won’t tell you about slices. So practically it’s a distinction you need to understand if you intend on working with them.

[anthk]

No, you slice up an OpenBSD partition (GPT/MBR/Apple...) into several parts (subvolumes to get mounted).

[nix23]

It's the same...GPT is the partition-table, you even write it yourself:

>into several parts

parts are partitions and not subvolumes, a subvolume is a filesystem or volume-manager on top of a partition and it's size/quota etc is defined BY the filesystem or the volume-manager (look up btrfs subvolumes, zfs-filesystems or lvm).

[daneel_w]

This is one of OpenBSD's shortcomings. While I like the fundamental design of all the file systems living contained within a "normal" MBR/GPT partition, the lack of advanced tools (no logical volume management, can only grow file systems but not shrink them etc.) has vexed me a couple of times during my 22 years of using OpenBSD. Thankfully it doesn't take long to get a good view of the storage requirements. I recommend playing around with OpenBSD in a virtual machine, e.g. VirtualBox or so.

[anthk]

With current SSD's speed and price just use dump(8) and restore(8) to and from external devices.

[messe]

I'm an OpenBSD user, and while that's a solution, it's not a good one. The poster is right, lack of a modern filesystem is a major shortcoming of OpenBSD; but sadly nobody with the right skill set has decided to work on that.

If I remember rightly there was some interest in porting HAMMER2 (DragonflyBSD's filesystem) to OpenBSD, but it's a lot of work with very few people both interested and experienced enough to put in the work.

[daneel_w]

Sure, or just roll a tar-ball etc. It's how to do it. It's just a bit of a round-about way, is all.

[anthk]

Yes. But most OpenBSD system partitions (anything but /home) get a pretty small size compared to the full disk, do dump/restore will work pretty fast.