Permit zpool create -o whole_disk=1

[ryao]

There are situations where it is desireable to set the whole_disk attribute so that ZFS will control the IO elevator, but ZFS does not permit it.

One scenario involved issue #1149, which resulted in an exception being added to the IO elevator behavior. Another scenario involves virtual machines on zvols. With raw disks, ZFS does partitioning and leaves space for an additional partition to be added for the bootloader. With zvols, ZFS does no partitioning. This poses a problem when a guest operating system's bootloader requires a separate partition to host its stage2 loader. If ZFS did do partitioning on zvols, we would lose flexibility when configuring pools on zvols.

In both scenarios, it would be helpful to override the default whole_disk attribute setting when creating the pool. This should be safe because the worst case scenario on Linux would be the use of a suboptimal IO elevator. This would only happen when the user explicitly requests it.

The rationale for whole_disk is stated on Wikipedia:

On Solaris, when entire disks are added to a ZFS pool, ZFS automatically enables their write cache. This is not done when ZFS only manages discrete slices of the disk, since it does not know if other slices are managed by non-write-cache safe filesystems, like UFS. The FreeBSD implementation can handle disk flushes for partitions thanks to its GEOM framework, and therefore does not suffer from this limitation

The consequence is that FreeBSD unconditionally sets whole_disk. While it could be undesirable to do the same, it should be perfectly fine to allow users to override the default choice when creating a pool.

[ryao]

@nedbass @prakash-surya Would this cover your use case?

[behlendorf]

@ryao Unfortunately no. Part of the issue is that when using dm device's it tricky to automatically determine what new dm partition device will be named. Unlike hd/sd/vd/md devices a partition suffix is not simply added, instead a new dmX device is created where X is just a monotonically increasing value. I'm sure a mapping could be created for this case, but thus far it hasn't been worth it to handle this case.

[behlendorf]

@ryao I'm chalking this up to a feature request. While ZFS usually does the right thing here I don't see any real issues with allowing the user to override that choice during zpool create. However, we'll also want to get the zpool attach, zpool add, and zpool replace cases.

[ryao]

@behlendorf This is a low priority. Given the large number of things queued for 0.6.3, it might be advisable to push this back to 0.6.4 or later.

[behlendorf]

Agreed, bumped to 0.6.4 for now and it may continue to be bumped.

[rlaager]

The elevator thing is gone or going away. I'm closing this in favor of #3452, which has more notes for an implementation.