This typedef is being done in both lib/libefi/include/sys/uuid.h and
/usr/include/uuid/uuid.h, both of which are included in lib/libefi/rdwr_efi.c.
This leads to the following error:
In file included from ../../lib/libefi/include/sys/efi_partition.h:29,
from ../../lib/libefi/rdwr_efi.c:41:
../../lib/libefi/include/sys/uuid.h:81: error: redefinition of typedef 'uuid_t'
/usr/include/uuid/uuid.h:19: note: previous declaration of 'uuid_t' was here
The reason that we didn't see this before, is because of a strange feature in
gcc where some types of warnings/errors are silently ignored if they come from
system headers. But depending on the order of how system headers end up
included, libefi's uuid.h may actually be included after uuid/uuid.h, which
leads to the error above.
It is safe to remove this duplicate typedef because we are already
dependent on the linux uuid.h header and it's exceptionally unlikely
they will ever change the size.
Based on the block device type we can expect a specific naming
convention. With this in mind update efi_get_info() to be more
aware of the type when parsing out the partition number. In,
addition be aware that all block device types are not partitionable.
Finally, when attempting to lookup a device partition by appending
the partition number to the whole device take in to account the
kernel naming scheme. If the last character of the device name
is a digit the partition will always be 'p#' instead of just '#'.
In check_disk() we should only check the entire device if it
not a whole disk. It is a whole disk with an EFI label on it,
it is possible that libblkid will misidentify the device as a
filesystem. I had a case yesterday where 2 bytes in the EFI
GUID happened we set to the right values such that libblkid
decided there was a minux filesystem there. If it's a whole
device we look for a EFI label.
If we are able to read the backup EFI label from a device but
the primary is corrupt. Then don't bother trying to stat
the partitions in /dev/ the kernel will not create devices
using the backup label when the primary is damaged.
Add code to determine if we have a udev path instead of a
normal device path. In this case use the -part# partition
naming scheme instead of the /dev/disk# scheme. This is
important because we always want to access devices using
the full path provided at configuration time.
Readded support for zpool_relabel_disk() now that we have
the full libefi library in place we do have access to this
functionality.
Lots of additional paranoia to ensure EFI label are written
correctly. These changes include:
1) Removing the O_NDELAY flag when opening a file descriptor
for libefi. This flag should really only be used when you
do not intend to do any file IO. Under Solaris only ioctl()'s
were performed under linux we do perform reads and writes.
2) Use O_DIRECT to ensure any caching is bypassed while
writing or reading the EFI labels. This change forces the
use of sector aligned memory buffers which are allocated
using posix_memalign().
3) Add additional efi_debug error messages to efi_ioctl().
4) While doing a fsync is good to ensure the EFI label is on
disk we can, and should go one step futher by issuing the
BLKFLSBUF ioctl(). This signals the kernel to instruct the
drive to flush it's on-disk cache.
5) Because of some initial strangeness I observed in testing
with some flakey drives be extra paranoid in zpool_label_disk().
After we've written the device without error, flushed the drive
caches, correctly detected the new partitions created by the
kernel. Then additionally read back the EFI label from user
space to make sure it is intact and correct. I don't think we
can ever be to careful here.
NOTE: The was recently some concern expressed that writing EFI
labels from user space on Linux was not the right way to do this.
That instead two kernel ioctl()s should be used to create and
remove partitions. After some investigation it's clear to me
using those ioctl() would be a bad idea. The in fact don't
actually write partition tables to the disk, they only create
the partition devices in the kernel. So what you really want
to do is write the label out from user space, then prompt the
kernel to re-read the partition from disk to create the partitions.
This is in fact exactly what newer version of parted do.
The major change here is to fix up libefi to be linux aware. For
the most part this wasn't too hard but there were a few major issues.
First off I needed to handle the DKIOCGMEDIAINFO and DKIOCINFO ioctls.
There is no direct equivilant for these ioctls under linux. To handle
this I added wrapper functions which under Solaris simple call the ioctls.
But under Linux dig around the system a little bit getting the needed
info to fill in the requested structures.
Secondly the efi_ioctl() call was adapted such that under linux it directly
read or writes out the partition table. Under Solaris this work was
handed off to the kernel via an ioctl. In the efi_write() case we also
ensure we prompt the kernel via BLKRRPART to re-scan the new partition
table. The libefi generated partition tables are correct but older
versions of ~parted-1.8.1 can not read them without a small patch.
The kernel and fdisk are able to read them just fine.
Thirdly efi_alloc_and_init() which is used by zpool to determine if a
device is a 'wholedisk' was updated to be linux aware. This check is
performed by using the partition number for the device, which the
partition number is 0 on linux it is a 'wholedisk'. However, certain
device type such as the loopback and ram disks needed to be excluded
because they do not support partitioning.
Forthly the zpool command was made symlink aware so it can correctly
resolve udev entries such as /dev/disk/by-*/*. This symlinks are
fully expanded ensuring all block devices are recognized. When a
when a 'wholedisk' block device is detected we now properly write
out an efi label and place zfs in the first partition (0th slice).
This partition is created 1MiB in to the disk to ensure it is aligned
nicely with all high end block devices I'm aware of.
This all works for me now but it did take quite a bit of work to get
it all sorted out. It would not surprise me if certain special cases
were missed so we should keep any eye of for any odd behavior.
Brian Behlendorf
Ricardo M. Correia