On 24.09.2015 09:29, Phil Susi wrote:
So it is kind of like that object storage stuff the SCSI committee has
been toying with for years? Where you give it a key and an arbitrary
data set to store associated with that key? And instead of using the
disk like that, you have to have a translation layer to make it behave
more like a regular disk?
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.
So instead of simply writing the VTOC to the first track, some crazy
person decided to make an ioctl for it, and when it is attached via
virtio, you skip this useless ioctl and just write to the first track
like a sane person? Why keep the ioctl for direct attached disks? Why
not just get rid of it in both cases?
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.
--
Mit freundlichen Grüßen/Kind Regards
Viktor Mihajlovski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
