#
99bb425d |
| 05-May-2022 |
Stefan Haberland <sth@linux.ibm.com> |
s390/dasd: fix data corruption for ESE devices
commit 5b53a405e4658580e1faf7c217db3f55a21ba849 upstream.
For ESE devices we get an error when accessing an unformatted track. The handling of this er
s390/dasd: fix data corruption for ESE devices
commit 5b53a405e4658580e1faf7c217db3f55a21ba849 upstream.
For ESE devices we get an error when accessing an unformatted track. The handling of this error will return zero data for read requests and format the track on demand before writing to it. To do this the code needs to distinguish between read and write requests. This is done with data from the blocklayer request. A pointer to the blocklayer request is stored in the CQR.
If there is an error on the device an ERP request is built to do error recovery. While the ERP request is mostly a copy of the original CQR the pointer to the blocklayer request is not copied to not accidentally pass it back to the blocklayer without cleanup.
This leads to the error that during ESE handling after an ERP request was built it is not possible to determine the IO direction. This leads to the formatting of a track for read requests which might in turn lead to data corruption.
Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Link: https://lore.kernel.org/r/20220505141733.1989450-2-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
bf5fb875 |
| 04-Aug-2021 |
Christoph Hellwig <hch@lst.de> |
dasd: use bvec_virt
Use bvec_virt instead of open coding it.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Link: https://lore.kernel.org/r/20210804
dasd: use bvec_virt
Use bvec_virt instead of open coding it.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Link: https://lore.kernel.org/r/20210804095634.460779-14-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
952835ed |
| 04-Aug-2021 |
Stefan Haberland <sth@linux.ibm.com> |
s390/dasd: fix use after free in dasd path handling
When new configuration data is obtained after a path event it is stored in the per path array. The old data needs to be freed. The first valid con
s390/dasd: fix use after free in dasd path handling
When new configuration data is obtained after a path event it is stored in the per path array. The old data needs to be freed. The first valid configuration data is also referenced in the device private structure to identify the device. When the old per path configuration data was freed the device still pointed to the already freed data leading to a use after free.
Fix by replacing also the device configuration data with the newly obtained one before the old data gets freed.
Fixes: 460181217a24 ("s390/dasd: Store path configuration data during path handling") Cc: stable@vger.kernel.org # 5.11+ Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Link: https://lore.kernel.org/r/20210804151800.4031761-2-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49 |
|
#
2b7a8dc0 |
| 01-Jul-2021 |
Kees Cook <keescook@chromium.org> |
s390/dasd: Avoid field over-reading memcpy()
In preparation for FORTIFY_SOURCE performing compile-time and run-time field array bounds checking for memcpy(), memmove(), and memset(), avoid intention
s390/dasd: Avoid field over-reading memcpy()
In preparation for FORTIFY_SOURCE performing compile-time and run-time field array bounds checking for memcpy(), memmove(), and memset(), avoid intentionally reading across neighboring array fields.
Add a wrapping structure to serve as the memcpy() source, so the compiler can do appropriate bounds checking, avoiding this future warning:
In function '__fortify_memcpy', inlined from 'create_uid' at drivers/s390/block/dasd_eckd.c:749:2: ./include/linux/fortify-string.h:246:4: error: call to '__read_overflow2_field' declared with attribute error: detected read beyond size of field (2nd parameter)
Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Link: https://lore.kernel.org/r/20210701142221.3408680-3-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
Revision tags: v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24 |
|
#
1987c551 |
| 16-Mar-2021 |
Julian Wiedmann <jwi@linux.ibm.com> |
s390/dasd: let driver core manage the sysfs attributes
Wire up device_driver->dev_groups, so that really_probe() creates the sysfs attributes for us automatically.
Signed-off-by: Julian Wiedmann <j
s390/dasd: let driver core manage the sysfs attributes
Wire up device_driver->dev_groups, so that really_probe() creates the sysfs attributes for us automatically.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Link: https://lore.kernel.org/r/20210316094513.2601218-3-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
Revision tags: v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
ac55ad2b |
| 18-Jan-2021 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Fix inconsistent kobject removal
Our intention was to only remove path kobjects whenever a device is being set offline. However, one corner case was missing.
If a device is disabled and
s390/dasd: Fix inconsistent kobject removal
Our intention was to only remove path kobjects whenever a device is being set offline. However, one corner case was missing.
If a device is disabled and enabled (using the IOCTLs BIODASDDISABLE and BIODASDENABLE respectively), the enabling process will call dasd_eckd_reload_device() which itself calls dasd_eckd_read_conf() in order to update path information. During that update, dasd_eckd_clear_conf_data() clears all old data and also removes all kobjects. This will leave us with an inconsistent state of path kobjects and a subsequent path verification leads to a failing kobject creation.
Fix this by removing kobjects only in the context of offlining a device as initially intended.
Fixes: 19508b204740 ("s390/dasd: Display FC Endpoint Security information via sysfs") Reported-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
Revision tags: v5.10 |
|
#
127fca60 |
| 10-Nov-2020 |
Vineeth Vijayan <vneethv@linux.ibm.com> |
s390/dasd: remove unused pm related functions
The power-management related functions are unused since the 'commit 394216275c7d ("s390: remove broken hibernate / power management support")'. Remove t
s390/dasd: remove unused pm related functions
The power-management related functions are unused since the 'commit 394216275c7d ("s390: remove broken hibernate / power management support")'. Remove them from dasd drivers.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9 |
|
#
4d063e64 |
| 08-Oct-2020 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Process FCES path event notification
If the Fibre Channel Endpoint-Security status of a path changes, a corresponding path event is received from the CIO layer.
Process this event by re-
s390/dasd: Process FCES path event notification
If the Fibre Channel Endpoint-Security status of a path changes, a corresponding path event is received from the CIO layer.
Process this event by re-reading the FCES information.
As the information is retrieved for all paths on a single CU in one call, the internal status can also be updated for all paths and no processing per path is necessary.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
b7294932 |
| 08-Oct-2020 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Prepare for additional path event handling
As more path events need to be handled for ECKD the current path verification infrastructure can be reused. Rename all path verifcation code to
s390/dasd: Prepare for additional path event handling
As more path events need to be handled for ECKD the current path verification infrastructure can be reused. Rename all path verifcation code to fit the more broadly based task of path event handling and put the path verification in a new separate function.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
19508b20 |
| 08-Oct-2020 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Display FC Endpoint Security information via sysfs
Add a new sysfs attribute (fc_security) per device and per operational channel path. The information of the current FC Endpoint Security
s390/dasd: Display FC Endpoint Security information via sysfs
Add a new sysfs attribute (fc_security) per device and per operational channel path. The information of the current FC Endpoint Security state is received through the CIO layer.
The state of the FC Endpoint Security can be either "Unsupported", "Authentication", or "Encryption".
For example: $ cat /sys/bus/ccw/devices/0.0.c600/fc_security Encryption
If any of the operational paths is in a state different from all others, the device sysfs attribute will display the additional state "Inconsistent".
The sysfs attributes per paths are organised in a new directory called "paths_info" with subdirectories for each path.
/sys/bus/ccw/devices/0.0.c600/paths_info/ ├── 0.38 │ └── fc_security ├── 0.39 │ └── fc_security ├── 0.3a │ └── fc_security └── 0.3b └── fc_security
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
9e34c8ba |
| 08-Oct-2020 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Fix operational path inconsistency
During online processing and setting up a DASD device, the configuration data for operational paths is read and validated two times (dasd_eckd_read_conf
s390/dasd: Fix operational path inconsistency
During online processing and setting up a DASD device, the configuration data for operational paths is read and validated two times (dasd_eckd_read_conf()). The first time to provide information that are necessary for the LCU setup. A second time after the LCU setup as a device might report different configuration data then.
When the configuration setup for each operational path is being validated, an initial call to dasd_eckd_clear_conf_data() is issued. This call wipes all previously available configuration data and path information for each path. However, the operational path mask is not updated during this process.
As a result, the stored operational path mask might no longer correspond to the operational paths mask reported by the CIO layer, as several paths might be gone between the two dasd_eckd_read_conf() calls.
This inconsistency leads to more severe issues in later path handling changes. Fix this by removing the channel paths from the operational path mask during the dasd_eckd_clear_conf_data() call.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
46018121 |
| 08-Oct-2020 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Store path configuration data during path handling
Currently, the configuration data for a path is retrieved during a path verification and used only temporarily. If a path is newly added
s390/dasd: Store path configuration data during path handling
Currently, the configuration data for a path is retrieved during a path verification and used only temporarily. If a path is newly added to the I/O setup after a boot, no configuration data will be stored for this particular path. However, this data is required for later use and should be present for a valid I/O path anyway. Store this data during the path verification so that newly added paths can provide all information necessary.
[sth@linux.ibm.com: fix conf_data memleak]
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
d2a52758 |
| 08-Oct-2020 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Move duplicate code to separate function
For storing retrieved path information both the if and else block in dasd_eckd_read_conf() use the same code. To avoid duplicate code this should
s390/dasd: Move duplicate code to separate function
For storing retrieved path information both the if and else block in dasd_eckd_read_conf() use the same code. To avoid duplicate code this should be done after the if/else block. To further increase readability, move the code to a new function, dasd_eckd_store_conf_data().
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
e03c5941 |
| 08-Oct-2020 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Remove unused parameter from dasd_generic_probe()
The discipline argument in dasd_generic_probe() isn't used and there is no history how it was used in the past. Remove it.
Signed-off-by
s390/dasd: Remove unused parameter from dasd_generic_probe()
The discipline argument in dasd_generic_probe() isn't used and there is no history how it was used in the past. Remove it.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
Revision tags: v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26 |
|
#
5e6bdd37 |
| 12-Mar-2020 |
Stefan Haberland <sth@linux.ibm.com> |
s390/dasd: fix data corruption for thin provisioned devices
Devices are formatted in multiple of tracks. For an Extent Space Efficient (ESE) volume we get errors when accessing unformatted tracks. I
s390/dasd: fix data corruption for thin provisioned devices
Devices are formatted in multiple of tracks. For an Extent Space Efficient (ESE) volume we get errors when accessing unformatted tracks. In this case the driver either formats the track on the flight for write requests or returns zero data for read requests.
In case a request spans multiple tracks, the indication of an unformatted track presented for the first track is incorrectly applied to all tracks covered by the request. As a result, tracks containing data will be handled as empty, resulting in zero data being returned on read, or overwriting existing data with zero on write.
Fix by determining the track that gets the NRF error. For write requests only format the track that is surely not formatted. For Read requests all tracks before have returned valid data and should not be touched. All tracks after the unformatted track might be formatted or not. Those are returned to the blocklayer to build a new request.
When using alias devices there is a chance that multiple write requests trigger a format of the same track which might lead to data loss. Ensure that a track is formatted only once by maintaining a list of currently processed tracks.
Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes") Cc: stable@vger.kernel.org # 5.3+ Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
Revision tags: v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6 |
|
#
00b39f69 |
| 19-Dec-2019 |
Stefan Haberland <sth@linux.ibm.com> |
s390/dasd: fix memleak in path handling error case
If for whatever reason the dasd_eckd_check_characteristics() function exits after at least some paths have their configuration data allocated those
s390/dasd: fix memleak in path handling error case
If for whatever reason the dasd_eckd_check_characteristics() function exits after at least some paths have their configuration data allocated those data is never freed again. In the error case the device->private pointer is set to NULL and dasd_eckd_uncheck_device() will exit without freeing the path data because of this NULL pointer.
Fix by calling dasd_eckd_clear_conf_data() for error cases.
Also use dasd_eckd_clear_conf_data() in dasd_eckd_uncheck_device() to avoid code duplication.
Reported-by: Qian Cai <cai@lca.pw> Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
dd4b3c83 |
| 19-Dec-2019 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd/cio: Interpret ccw_device_get_mdc return value correctly
The max data count (mdc) is an unsigned 16-bit integer value as per AR documentation and is received via ccw_device_get_mdc() for a
s390/dasd/cio: Interpret ccw_device_get_mdc return value correctly
The max data count (mdc) is an unsigned 16-bit integer value as per AR documentation and is received via ccw_device_get_mdc() for a specific path mask from the CIO layer. The function itself also always returns a positive mdc value or 0 in case mdc isn't supported or couldn't be determined.
Though, the comment for this function describes a negative return value to indicate failures.
As a result, the DASD device driver interprets the return value of ccw_device_get_mdc() incorrectly. The error case is essentially a dead code path.
To fix this behaviour, check explicitly for a return value of 0 and change the comment for ccw_device_get_mdc() accordingly.
This fix merely enables the error code path in the DASD functions get_fcx_max_data() and verify_fcx_max_data(). The actual functionality stays the same and is still correct.
Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
Revision tags: v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3 |
|
#
964ce509 |
| 01-Oct-2019 |
Stefan Haberland <sth@linux.ibm.com> |
Revert "s390/dasd: Add discard support for ESE volumes"
This reverts commit 7e64db1597fe114b83fe17d0ba96c6aa5fca419a.
The thin provisioning feature introduces an IOCTL and the discard support to al
Revert "s390/dasd: Add discard support for ESE volumes"
This reverts commit 7e64db1597fe114b83fe17d0ba96c6aa5fca419a.
The thin provisioning feature introduces an IOCTL and the discard support to allow userspace tools and filesystems to release unused and previously allocated space respectively.
During some internal performance improvements and further tests, the release of allocated space revealed some issues that may lead to data corruption in some configurations when filesystems are mounted with discard support enabled.
While we're working on a fix and trying to clarify the situation, this commit reverts the discard support for ESE volumes to prevent potential data corruption.
Cc: <stable@vger.kernel.org> # 5.3 Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
dd454839 |
| 01-Oct-2019 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Fix error handling during online processing
It is possible that the CCW commands for reading volume and extent pool information are not supported, either by the storage server (for dedica
s390/dasd: Fix error handling during online processing
It is possible that the CCW commands for reading volume and extent pool information are not supported, either by the storage server (for dedicated DASDs) or by z/VM (for virtual devices, such as MDISKs).
As a command reject will occur in such a case, the current error handling leads to a failing online processing and thus the DASD can't be used at all.
Since the data being read is not essential for an fully operational DASD, the error handling can be removed. Information about the failing command is sent to the s390dbf debug feature.
Fixes: c729696bcf8b ("s390/dasd: Recognise data for ESE volumes") Cc: <stable@vger.kernel.org> # 5.3 Reported-by: Frank Heimes <frank.heimes@canonical.com> Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
Revision tags: v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4 |
|
#
9e12e54c |
| 03-Jul-2018 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Handle out-of-space constraint
The storage server issues three different types of out-of-space messages whenever the Extent Pool or Extent Repository space runs short. When a configured w
s390/dasd: Handle out-of-space constraint
The storage server issues three different types of out-of-space messages whenever the Extent Pool or Extent Repository space runs short. When a configured warning watermark is reached, the physical space is completeley exhausted, or the capacity constraints have been relieved, a message is received.
A log entry for the sysadmin to react to is generated in any case. In case the physical space is completely exhausted, sense data that reads "no space left on device" is received. In this case, currently running I/O will be blocked until space has either been released or added to the extent pool, and a relieve message was received via an attention interrupt.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
Revision tags: v4.17.3, v4.17.2, v4.17.1, v4.17 |
|
#
7e64db15 |
| 27-Apr-2018 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Add discard support for ESE volumes
ESE (Extent Space Efficient) volumes are thin-provisioned and therefore space is only occupied with real data. In order to make previously used space a
s390/dasd: Add discard support for ESE volumes
ESE (Extent Space Efficient) volumes are thin-provisioned and therefore space is only occupied with real data. In order to make previously used space available for re-allocation again, discard support is enabled for ESE volumes allowing the DASD driver to release said space.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
a0610a8a |
| 27-Apr-2018 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Make dasd_setup_queue() a discipline function
ECKD, FBA, and the DIAG discipline use slightly different block layer settings. In preparation of even more diverse queue settings, make dasd
s390/dasd: Make dasd_setup_queue() a discipline function
ECKD, FBA, and the DIAG discipline use slightly different block layer settings. In preparation of even more diverse queue settings, make dasd_setup_queue() a discipline function.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
91dc4a19 |
| 23-Jul-2018 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Add new ioctl to release space
Userspace tools might have the need to release space for Extent Space Efficient (ESE) volumes when working with such a device.
Provide the necessarry inter
s390/dasd: Add new ioctl to release space
Userspace tools might have the need to release space for Extent Space Efficient (ESE) volumes when working with such a device.
Provide the necessarry interface for such a task by implementing a new ioctl BIODASDRAS. The ioctl uses the format_data_t data structure for data input:
typedef struct format_data_t { unsigned int start_unit; /* from track */ unsigned int stop_unit; /* to track */ unsigned int blksize; /* sectorsize */ unsigned int intensity; } format_data_t;
If the intensity is set to 0x40, start_unit and stop_unit are ignored and space for the entire volume is released. Otherwise, if intensity is set to 0, the respective range is released (if possible).
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
5e2b17e7 |
| 27-Apr-2018 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Add dynamic formatting support for ESE volumes
A dynamic formatting is issued whenever a write request returns with either a No Record Found error (Command Mode), Incorrect Length error (
s390/dasd: Add dynamic formatting support for ESE volumes
A dynamic formatting is issued whenever a write request returns with either a No Record Found error (Command Mode), Incorrect Length error (Transport Mode), or File Protected error (Transport Mode). All three cases mean that the tracks in question haven't been initialized in a desired format yet.
The part of the volume that was tried to be written on is then formatted and the original request is re-queued.
As the formatting will happen during normal I/O operations, it is quite likely that there won't be any memory available to build the respective request. Another two pages of memory are allocated per volume specifically for the dynamic formatting.
The dasd_eckd_build_format() function is extended to make sure that the original startdev is reused. Also, all formatting and format check functions use the new memory pool exclusively now to reduce complexity.
Read operations will always return zero data when unformatted areas are read.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|
#
c729696b |
| 29-May-2018 |
Jan Höppner <hoeppner@linux.ibm.com> |
s390/dasd: Recognise data for ESE volumes
In order to work with Extent Space Efficient (ESE) volumes, certain viable information about those volumes and the corresponding extent pool (such as extent
s390/dasd: Recognise data for ESE volumes
In order to work with Extent Space Efficient (ESE) volumes, certain viable information about those volumes and the corresponding extent pool (such as extent size, configured space, allocated space, etc.) can be provided.
Use the CCW commands Volume Storage Query and Logical Configuration Query to receive detailed information about ESE volumes and the extent pool respectively. These information are made accessible via internal functions for subsequent users, and via sysfs attributes for userpsace usage.
The new sysfs attributes reside in separate directories called capacity and extent_pool.
attributes: ese: 0/1 depending on whether the volume is an ESE volume
Capacity related attributes: space_allocated: Space currently allocated by the volume (in cyl) space_configured: Remaining space in the extent pool (in cyl) logical_capacity: The entire addressable space for this volume (in cyl)
Extent Pool related attributes: pool_id: ID of the extent pool the volume in question resides in pool_oos: Extent pool is out-of-space extent_size: Size of a single extent in this pool cap_at_warnlevel Extent pool capacity at warn level warn_threshold: Threshold at which percentage of remaining extent pool space a warning message is issued
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com> Reviewed-by: Stefan Haberland <sth@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
show more ...
|