Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame^] | 1 | DASD device driver |
| 2 | |
| 3 | S/390's disk devices (DASDs) are managed by Linux via the DASD device |
| 4 | driver. It is valid for all types of DASDs and represents them to |
| 5 | Linux as block devices, namely "dd". Currently the DASD driver uses a |
| 6 | single major number (254) and 4 minor numbers per volume (1 for the |
| 7 | physical volume and 3 for partitions). With respect to partitions see |
| 8 | below. Thus you may have up to 64 DASD devices in your system. |
| 9 | |
| 10 | The kernel parameter 'dasd=from-to,...' may be issued arbitrary times |
| 11 | in the kernel's parameter line or not at all. The 'from' and 'to' |
| 12 | parameters are to be given in hexadecimal notation without a leading |
| 13 | 0x. |
| 14 | If you supply kernel parameters the different instances are processed |
| 15 | in order of appearance and a minor number is reserved for any device |
| 16 | covered by the supplied range up to 64 volumes. Additional DASDs are |
| 17 | ignored. If you do not supply the 'dasd=' kernel parameter at all, the |
| 18 | DASD driver registers all supported DASDs of your system to a minor |
| 19 | number in ascending order of the subchannel number. |
| 20 | |
| 21 | The driver currently supports ECKD-devices and there are stubs for |
| 22 | support of the FBA and CKD architectures. For the FBA architecture |
| 23 | only some smart data structures are missing to make the support |
| 24 | complete. |
| 25 | We performed our testing on 3380 and 3390 type disks of different |
| 26 | sizes, under VM and on the bare hardware (LPAR), using internal disks |
| 27 | of the multiprise as well as a RAMAC virtual array. Disks exported by |
| 28 | an Enterprise Storage Server (Seascape) should work fine as well. |
| 29 | |
| 30 | We currently implement one partition per volume, which is the whole |
| 31 | volume, skipping the first blocks up to the volume label. These are |
| 32 | reserved for IPL records and IBM's volume label to assure |
| 33 | accessibility of the DASD from other OSs. In a later stage we will |
| 34 | provide support of partitions, maybe VTOC oriented or using a kind of |
| 35 | partition table in the label record. |
| 36 | |
| 37 | USAGE |
| 38 | |
| 39 | -Low-level format (?CKD only) |
| 40 | For using an ECKD-DASD as a Linux harddisk you have to low-level |
| 41 | format the tracks by issuing the BLKDASDFORMAT-ioctl on that |
| 42 | device. This will erase any data on that volume including IBM volume |
| 43 | labels, VTOCs etc. The ioctl may take a 'struct format_data *' or |
| 44 | 'NULL' as an argument. |
| 45 | typedef struct { |
| 46 | int start_unit; |
| 47 | int stop_unit; |
| 48 | int blksize; |
| 49 | } format_data_t; |
| 50 | When a NULL argument is passed to the BLKDASDFORMAT ioctl the whole |
| 51 | disk is formatted to a blocksize of 1024 bytes. Otherwise start_unit |
| 52 | and stop_unit are the first and last track to be formatted. If |
| 53 | stop_unit is -1 it implies that the DASD is formatted from start_unit |
| 54 | up to the last track. blksize can be any power of two between 512 and |
| 55 | 4096. We recommend no blksize lower than 1024 because the ext2fs uses |
| 56 | 1kB blocks anyway and you gain approx. 50% of capacity increasing your |
| 57 | blksize from 512 byte to 1kB. |
| 58 | |
| 59 | -Make a filesystem |
| 60 | Then you can mk??fs the filesystem of your choice on that volume or |
| 61 | partition. For reasons of sanity you should build your filesystem on |
| 62 | the partition /dev/dd?1 instead of the whole volume. You only lose 3kB |
| 63 | but may be sure that you can reuse your data after introduction of a |
| 64 | real partition table. |
| 65 | |
| 66 | BUGS: |
| 67 | - Performance sometimes is rather low because we don't fully exploit clustering |
| 68 | |
| 69 | TODO-List: |
| 70 | - Add IBM'S Disk layout to genhd |
| 71 | - Enhance driver to use more than one major number |
| 72 | - Enable usage as a module |
| 73 | - Support Cache fast write and DASD fast write (ECKD) |