diff options
author | Akinobu Mita <akinobu.mita@gmail.com> | 2013-04-16 22:11:58 +0900 |
---|---|---|
committer | James Bottomley <JBottomley@Parallels.com> | 2013-05-02 15:45:56 -0700 |
commit | b90ebc3d5c41c9164ae04efd2e4f8204c2a186f1 (patch) | |
tree | b74225a28bb0322c6cb755349abc7a8299198c2c /Documentation/kernel-parameters.txt | |
parent | cc34a8e663b2908b9ab487dab8456d117a1e0b93 (diff) | |
download | op-kernel-dev-b90ebc3d5c41c9164ae04efd2e4f8204c2a186f1.zip op-kernel-dev-b90ebc3d5c41c9164ae04efd2e4f8204c2a186f1.tar.gz |
[SCSI] scsi_debug: fix logical block provisioning support
provisioning map (map_storep) is a bitmap accessed by bitops.
So the allocation size should be a multiple of sizeof(unsigned long) and
also the bitmap should be cleared by using bitmap_clear() instead of
memset().
Otherwise it will cause problem on big-endian architecture if the number of
bits is not a multiple of BITS_PER_LONG.
I tried testing the logical block provisioning support in scsi_debug,
but it didn't work as I expected.
For example, load scsi_debug module with UNMAP command supported
and fill the storage with random data.
# modprobe scsi_debug lbpu=1
# dd if=/dev/urandom of=/dev/sdb
Then, try to unmap LBA 0, but Get LBA status reports:
# sg_unmap --lba=0 --num=1 /dev/sdb
# sg_get_lba_status --lba=0 /dev/sdb
descriptor LBA: 0x0000000000000000 blocks: 16384 mapped
This is unexpected result. Because UNMAP command to LBA 0 finished
without any errors, but Get LBA status shows that LBA 0 is still mapped.
This problem is due to the wrong translation between LBA and index of
provisioning map. Fix it by using correct translation functions.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Diffstat (limited to 'Documentation/kernel-parameters.txt')
0 files changed, 0 insertions, 0 deletions