by the number of concurrent I/O requests. Also introduce a new disk_wait()
function to measure requests waiting in a bufq.
iostat -y now reports data about waiting and active requests.
So far only drivers using dksubr and dk, ccd, wd and xbd collect data about
waiting requests.
The UEFI 2.3.1 specification states that:
"A minimum of 16,384 bytes of space must be reserved for the GPT Partition Entry Array."
and [the size of a partition entry shall be a power of two greater than 128]
and that [the defined fields of a partition entry total 128 bytes].
Clamping the entries means that no partitions on the drive will be detected,
as this will result in an incorrect partition entry array CRC. This change
reduces the likelyhood of useless partitions, while still not allowing a
huge kernel memory allocation to load the partition entries into.
In the future this code should probably be reworked to checksum and evaluate
the partition array in chunks while still limiting the number of GPT
wedges added per drive to something reasonable.
to the disk subsystem.
Make disk_set_info also set blocksize shift values.
Remove every call to disk_blocksize.
Keep disk_blocksize for ABI compatibility, make it also set dg_secsize.
type string, use the strings defined in DKW_PTYPE_* in <sys/disk.h>, not
the strings defined in FSTYPE_DEFN in <sys/disklabel.h>.
This corrects a problem introduced in revision 1.21 dated 2014-08-18.
That change was intended to add additional case to the list, but it
accidentally also changed from the strings in the DKW_PTYPE_* macros to
the strings in the FSTYPE_DEFN macro. Many of the strings are the same,
but there are differences such as "RAID" versus "raidframe" and "MSDOS"
versus "FAT".
XXX: There seems to be no good reason for the differences in string
names for partition types. One or both of the lists should probably be
edited to align them.
Otherwise, anything mounted with `-o discard' will pretty quickly
munch itself up and barf up an unrecoverably corrupted file system!
XXX pullup to netbsd-7
designated initializers.
I have not built every extant kernel so I have probably broken at
least one build; however I've also found and fixed some wrong
cdevsw/bdevsw entries so even if so I think we come out ahead.
