forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 435
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kerne…
…l/git/axboe/linux-block into rust-dev Conflicts: rust/bindings/bindings_helper.h
- Loading branch information
Showing
1,515 changed files
with
22,249 additions
and
12,785 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -21,6 +21,59 @@ Description: | |
| device is offset from the internal allocation unit's | ||
| natural alignment. | ||
|
|
||
| What: /sys/block/<disk>/atomic_write_max_bytes | ||
| Date: February 2024 | ||
| Contact: Himanshu Madhani <[email protected]> | ||
| Description: | ||
| [RO] This parameter specifies the maximum atomic write | ||
| size reported by the device. This parameter is relevant | ||
| for merging of writes, where a merged atomic write | ||
| operation must not exceed this number of bytes. | ||
| This parameter may be greater than the value in | ||
| atomic_write_unit_max_bytes as | ||
| atomic_write_unit_max_bytes will be rounded down to a | ||
| power-of-two and atomic_write_unit_max_bytes may also be | ||
| limited by some other queue limits, such as max_segments. | ||
| This parameter - along with atomic_write_unit_min_bytes | ||
| and atomic_write_unit_max_bytes - will not be larger than | ||
| max_hw_sectors_kb, but may be larger than max_sectors_kb. | ||
|
|
||
|
|
||
| What: /sys/block/<disk>/atomic_write_unit_min_bytes | ||
| Date: February 2024 | ||
| Contact: Himanshu Madhani <[email protected]> | ||
| Description: | ||
| [RO] This parameter specifies the smallest block which can | ||
| be written atomically with an atomic write operation. All | ||
| atomic write operations must begin at a | ||
| atomic_write_unit_min boundary and must be multiples of | ||
| atomic_write_unit_min. This value must be a power-of-two. | ||
|
|
||
|
|
||
| What: /sys/block/<disk>/atomic_write_unit_max_bytes | ||
| Date: February 2024 | ||
| Contact: Himanshu Madhani <[email protected]> | ||
| Description: | ||
| [RO] This parameter defines the largest block which can be | ||
| written atomically with an atomic write operation. This | ||
| value must be a multiple of atomic_write_unit_min and must | ||
| be a power-of-two. This value will not be larger than | ||
| atomic_write_max_bytes. | ||
|
|
||
|
|
||
| What: /sys/block/<disk>/atomic_write_boundary_bytes | ||
| Date: February 2024 | ||
| Contact: Himanshu Madhani <[email protected]> | ||
| Description: | ||
| [RO] A device may need to internally split an atomic write I/O | ||
| which straddles a given logical block address boundary. This | ||
| parameter specifies the size in bytes of the atomic boundary if | ||
| one is reported by the device. This value must be a | ||
| power-of-two and at least the size as in | ||
| atomic_write_unit_max_bytes. | ||
| Any attempt to merge atomic write I/Os must not result in a | ||
| merged I/O which crosses this boundary (if any). | ||
|
|
||
|
|
||
| What: /sys/block/<disk>/diskseq | ||
| Date: February 2021 | ||
|
|
||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -153,18 +153,11 @@ bio_free() will automatically free the bip. | |
| 4.2 Block Device | ||
| ---------------- | ||
|
|
||
| Because the format of the protection data is tied to the physical | ||
| disk, each block device has been extended with a block integrity | ||
| profile (struct blk_integrity). This optional profile is registered | ||
| with the block layer using blk_integrity_register(). | ||
|
|
||
| The profile contains callback functions for generating and verifying | ||
| the protection data, as well as getting and setting application tags. | ||
| The profile also contains a few constants to aid in completing, | ||
| merging and splitting the integrity metadata. | ||
| Block devices can set up the integrity information in the integrity | ||
| sub-struture of the queue_limits structure. | ||
|
|
||
| Layered block devices will need to pick a profile that's appropriate | ||
| for all subdevices. blk_integrity_compare() can help with that. DM | ||
| for all subdevices. queue_limits_stack_integrity() can help with that. DM | ||
| and MD linear, RAID0 and RAID1 are currently supported. RAID4/5/6 | ||
| will require extra work due to the application tag. | ||
|
|
||
|
|
@@ -250,42 +243,6 @@ will require extra work due to the application tag. | |
| integrity upon completion. | ||
|
|
||
|
|
||
| 5.4 Registering A Block Device As Capable Of Exchanging Integrity Metadata | ||
| -------------------------------------------------------------------------- | ||
|
|
||
| To enable integrity exchange on a block device the gendisk must be | ||
| registered as capable: | ||
|
|
||
| `int blk_integrity_register(gendisk, blk_integrity);` | ||
|
|
||
| The blk_integrity struct is a template and should contain the | ||
| following:: | ||
|
|
||
| static struct blk_integrity my_profile = { | ||
| .name = "STANDARDSBODY-TYPE-VARIANT-CSUM", | ||
| .generate_fn = my_generate_fn, | ||
| .verify_fn = my_verify_fn, | ||
| .tuple_size = sizeof(struct my_tuple_size), | ||
| .tag_size = <tag bytes per hw sector>, | ||
| }; | ||
|
|
||
| 'name' is a text string which will be visible in sysfs. This is | ||
| part of the userland API so chose it carefully and never change | ||
| it. The format is standards body-type-variant. | ||
| E.g. T10-DIF-TYPE1-IP or T13-EPP-0-CRC. | ||
|
|
||
| 'generate_fn' generates appropriate integrity metadata (for WRITE). | ||
|
|
||
| 'verify_fn' verifies that the data buffer matches the integrity | ||
| metadata. | ||
|
|
||
| 'tuple_size' must be set to match the size of the integrity | ||
| metadata per sector. I.e. 8 for DIF and EPP. | ||
|
|
||
| 'tag_size' must be set to identify how many bytes of tag space | ||
| are available per hardware sector. For DIF this is either 2 or | ||
| 0 depending on the value of the Control Mode Page ATO bit. | ||
|
|
||
| ---------------------------------------------------------------------- | ||
|
|
||
| 2007-12-24 Martin K. Petersen <[email protected]> | ||
Oops, something went wrong.