Disable automatic partitioning

[behlendorf]

Originally from #3448. A duplicate of, or related to, #94. #1162, #719 and possibility others. It would be a nice feature to have.

I'll add that absence of a means to directly utilize a blockdev without partitioning it is a source of rather minor annoyance on a VM. It inhibits ease of growing the zpool utilizing the device as it necessitates first growing the partition, and partprobe oft fails on live systems. I've worked around that with an LVM layer as-is.

This behavior would be fairly straight forward to make configurable. The place to start would be to look at make_leaf_vdev() where it determines if the device is a wholedisk or not. If it's determined to be a wholedisk then it will be automatically partitioned with some reasonable default values. Otherwise, the passed device is just treated as a partition with no special handling.

To get the desired behavior of not creating a partition table zpool create just needs to somehow communicate to make_leaf_vdev() that the vdev should not be considered a wholedisk even if it normally would be. Eventually else should just fallout automatically after that.

[Bronek]

Can we get this released?

[FransUrbo]

This have been running in the Debian GNU/Linux Wheezy and Jessie packages for quite a while and no one have complained :).

[FransUrbo]

Sorry, ignore. It was another patch I was thinking of...

[tuxoko]

What would be the problem if we don't ever do partitioning?

[behlendorf]

Functionally we wouldn't loose anything except some automatic performance tunings which are only done when ZFS knows it owns the entire block device. Cosmetically it would mean that the default zpool create behavior on Linux would differ from illumos.

[kim0]

It's really annoying that I have to juggle with partitions to autoexpand my pool. I expand it a lot, so this is annoying indeed! Please make an option I really mean whole disks :)

[kode54]

I don't know about you, but the last three pools I've created with whole device provisioning have only created GPT tables with partition 1 containing the bulk of the drive, partition 9 containing 8MB of Sun reserved data, 1MB of free space at the head of the drive, and about 512KB of free space on the end of the drive.

I had to explicitly create my own partition table and attach ZFS to part1 to make use of a GPT partition on my root volume.

Maybe this was added post-0.6.5.6, as that's what I've been using on Ubuntu.

[jumbi77]

Someone planning to work on that? I also find the new property partition = < raw | default | gpt > (see #3458) the best way.

[CMCDragonkai]

Is there also a way to change the size of the EFI System Partition when it is automatically created? And what happens if I had manually created a EFI System Partition (for installing the bootloader) using other tools, and installed ZFS on a partition instead of the whole disk, does this mean there are 2 EFI System Partitions on the disk?

[galaxy001]

I find the sda9 of 'BF07' partition can be used for uefi boot ONLY when formatted as 'FAT12'.

I wonder will zpool/zfs ensure that the contents within sda9 will always been kept even when the block device expands to a larger size (zpool online -e) ?

[behlendorf]

even when the block device expands to a larger size

They will not.

[pepa65]

Functionally we wouldn't loose anything except some automatic performance tunings which are only done when ZFS knows it owns the entire block device. Cosmetically it would mean that the default zpool create behavior on Linux would differ from illumos.

It seems that not partitioning is now the default on Illuminos, only when given the -B flag on zfs create will a GPT partitioning setup be done.

[koitsu]

@behlendorf I'm a commenter from #94 who is wondering what the status of this is on Linux.

This annoyance has existed for at least 12 years. On a simple 6-disk pool purely for storage (not bootable) on Linux, you end up with literally 18 partitions, none of which technically serve a good purpose (I could accept 6 partitions if needed, re: avoiding primary and secondary GPTs).

We don't have this problem on Solaris, FreeBSD (underlying layers will avoid the GPT regions, but if you want a bootable pool additional steps are required), and now (per previous comment) also Illumos (I love their -B solution -- nice and elegant for people who want a bootable pool).

[Low-power]

I want complain here because this behavior actually prevented me to make a root-on-ZFS VDEV bootable.

If I configure a VDEV without any partition, I can install GRUB for PC (i386-pc), and boot from it perfectly. But with this automatically created GPT, booting is not possible without a BIOS boot partition in that GPT.

Sometimes I just creates pools on FreeBSD to avoid this issue, then move the devices to a Linux-based system; more commonly I uses the loop devices to trick it so no GPT will be created. But other than zpool create, adding VDEV as part of other actions (zpool add, zpool attach, zpool replace) is harder to cope.

[thoro]

@Low-power How do you do this with the loop devices?

Edit:

losetup -f /dev/nvme4n1

worked for me, be mindful of the already existing loop devices in Talos

[ehem]

@thoro it doesn't require loop devices, the original experiment used hard links. Ultimately it appears anything ending with a non-zero number (the '1' on the end of "/dev/nvme4n1" qualifies) will be wholly used.

In fact this is actually a bug in the original bug (that is too awful to qualify as a misfeature). NVMe devices will never be detected as whole devices, which means this is completely broken.

[pepa65]

NVMe devices will never be detected as whole devices, which means this is completely broken.

Yes, the whole automatic partitioning feature is not just undesirable, it has been badly implemented. Please fix this!!

(That said, it makes it easier to use a whole NVMe device..!)

[thoro]

@ehem This is weird, I used /dev/disk/by-id/nvme-uuid.99db755f-2bf1-4ef2-9e41-773a58179c35 and that was definitly partitioned and created quite an headache for me.

It works now with loop devices, and also if the device is lvm.

[ehem]

@thoro I don't know what algorithm is used to flag devices as being whole devices or not. Guessing /dev/disk/by-id/nvme-uuid.99db755f-2bf1-4ef2-9e41-773a58179c35 got flagged as whole since it doesn't end with -part###. Yet most things directly in /dev with a name ending <something>1 are fully utilized.

Whatever the algorithm is the false positives and false negatives are so common that it is worthless. This is really a general issue of it is difficult to reliably distinguish whole versus part without plugging into udev. Another trick is if you're inside a VM (quite common, smaller file-servers rarely need all of a computer) anything you have could have been split outside the VM.