[OpenIndiana-discuss] slicing a disk for ZIL

[Jim Klimov]

On 2012-11-29 12:43, Sebastian Gabler wrote:
> I have bought and installed an Intel SSD 313 20 GB to use as ZIL for one
> or many pools. I am running openindiana on a x86 platform, no SPARC. As
> 4 GB should suffice, I am considering to partition the drive in order to
> assign each partition to one pool (ATM pools are 2 on the Server, but I
> could expand it in the future)
> After some reading, I am still confused about slicing and partitioning.
> What do I actually need to do to achieve the wanted effect to have up to
> 4 partions on that SSD?


Well, basically you need to partition the SSD :)

There are several options available:
1) Use MBR (MSDOS Boot Record) traditional partitions - up to four
    primary partitions, one (or more?) of which can allocate a range
    as a secondary (or extended) partition and store more parts there.

    In this case you would address your zfs "log" devices as cXtYdZpN.
    In case of IDE connection (which you don't want) you see cXdZpN.
    Here "N" is the partition number, with "0" being the partition
    table/whole disk itself, so your logs would be N=1,2,3,4 if you
    only use primary partitions (the whole disk should be divided
    between them, then. Extended partitions are addressed at N=5..15.

2) Use MBR with Solaris slices - define a "Solaris" partition in MBR
    using the whole disk, and define Solaris slices inside. Note that
    slice #2 is reserved as traditional "whole disk" for backup tools.
    It may cause zfs tools to report conflicts (slice overlaps), but
    you can ignore them.

    In this case your zfs "log" devices would be cXtYdZsN, with N being
    the slice number (0..7, 2 is reserved but can be reused if required).

    AFAIK you can't define more than one Solaris slice set on one HDD,
    though you can use other partitions for other filesystems. Maybe
    you can mix slices and partitions as components for the pool and
    its log/cache devices, but I won't bet on this.

3) Use a GPT (GUID Partition Table, maybe aka "EFI") partitioning
    table. There you explicitly define many partitions, all primary,
    that can be used by your pools and their components (logs/caches).

    I think, Solaris "format" utility detects a GPT table and uses
    (and displays) those partitions in place of slices for traditional
    MBR+slice tables. I.e. with GPT you don't have slices, and usually
    don't need to - you can have many more GPT partitions than slices.

    When you dedicate a whole disk to ZFS to use in a non-root pool,
    it essentially makes a GPT table with an 8Mb reserved tail partition
    and the rest is a ZFS partition.

    As of now, the GPT-tabled disks can not be used for bootable root
    pools with Solaris-derived OSes (maybe usable with other distros
    and another GRUB in particular).

I think you can not use separate ZIL with root pools - for mostly
the same reasons only mirrors/single disks are allowed (the single
device passed from BIOS/bootloader must be sufficient to boot the
OS image). Maybe you can attach an L2ARC cache to an rpool, though.

Also note that when using a sliced/partitioned disk with ZFS, you
might need to ensure that disk caching is on for this device. This
can be scripted as a bootup init-script calling "format", if required.
I think I or Edward Ned Harvey published variants of such scripts
in zfs-discuss mailing list this year.

Finally, you can use "(g)parted" and/or "fdisk" utilities to label
a disk as having a particular table and its contents. For slices or
partitions accessible to Solaris, and to configure some options like
cache, you further use "format" utility and follow its text menu.

HTH,
//Jim Klimov