[parted-devel] [PATCH 1/2] fdasd: geometry handling updated from upstream s390-tools

[Phil Susi]

On 9/25/2015 9:58 AM, Viktor Mihajlovski wrote:
> it is not exactly like that. If you think of traditional SCSI disks as a
> string of same sized blocks, a DASD can be thought of as a string of
> same sized tracks. Each of the tracks will contain records consisting of
> a count (length) field, an optional key field, and the data itself.
> Nothing a Linux filesystem would be able to consume.
> The formatting makes sure that all of the records in a track have the
> same length and no key field. A DASD formatted this way can be
> represented as a regular block device by the DASD driver.

How strange... why on earth does IBM make such odd disks?

> OK, I was simplifying a bit, so let me be more precise. The first track
> contains meta-data (the so called VOLSER), pointing to the actual VTOC
> record.
> The architectural compliant way (only possible for a natively attached
> DASD) to locate the VTOC is to use native s390 I/O which makes it
> necessary to use ioctls.
> For practical purposes, the VTOC of disks formatted by the Linux dasdfmt
> tool will be located in track 2, which is therefore the only valid
> layout for virtio attached DASD.
> In neither case (traditional or virtio) an ioctl is used to read or
> write the VTOC content.

So there is some out of band DASD hardware specific way of locating
where the VTOC is, and to handle it being in a different location, you
want to keep the ioctl, but in the virtio case, you just assume it's in
the normal location since you can't get the ioctl passed through, and
anyone who doesn't have it in the usual location is out of luck?