Hi Martin,
I had assumed that the VPD values for the LUNs were valid, and hadn't
even thought to check if they were standards-compliant. Based on the
SBC descriptions, it is clear that you are correct and this is an
issue with the storage not reporting a proper max_ws_blocks. At least
now I have
David Buckley writes:
David,
> The underlying issue seems to be that (per VPD page) the maximum
> supported unmap request is 8192 * 512 = 4194304 bytes, while the
> maximum write same request is 0x4000 * 512 = 8388608 bytes. It
> appears both of these values are correct, and in the case where a
Hi Martin,
I have identified the key difference between the older working kernels
and newer ones; on older kernels the provisioning_mode is set to
'unmap', while on newer kernels it is 'writesame_16'. This is due to
a change in sd_read_block_limits which prevents selection of
SD_LBP_UNMAP if the
David,
> I am wondering if part of the issue is that in my use case, UNMAP and
> WRITE SAME zeros result in very different results. With thin
> provisioned LUNs, UNMAP requests result in the blocks being freed and
> thus reduces the actual size of the LUN allocation on disk. If WRITE
> SAME req
(re-sending as I somehow lost the subject on my previous reply)
Martin,
I'm rather surprised nobody else has previously reported this as well,
especially as NetApp hadn't received any reports. The only probable
explanation I could think of is that EL 7 is still based on a 3.10
kernel so is too o
David Buckley writes:
David,
> As I mentioned previously, I'm fairly certain that the issue I'm
> seeing is due to the fact that while NetApp LUNs are presented as 512B
> logical/4K physical disks for compatibility, they actually don't
> support requests smaller than 4K (which makes sense as Net
Hi Martin,
I really appreciate the response. Here is the VPD page data you asked for:
Logical block provisioning VPD page (SBC):
Unmap command supported (LBPU): 1
Write same (16) with unmap bit supported (LBWS): 1
Write same (10) with unmap bit supported (LBWS10): 1
Logical block provisio
David Buckley writes:
David,
> They result in discard granularity being forced to logical block size
> if the disk reports LBPRZ is enabled (which the netapp luns do).
Block zeroing and unmapping are currently sharing some plumbing and that
has lead to some compromises. In this case a bias towa
Hello,
Hopefully this is the right place for this, and apologies for the
lengthy mail. I'm struggling with an issue with SCSI UNMAP/discard in
newer kernels, and I'm hoping to find a resolution or at least to
better understand why this has changed.
Some background info:
Our Linux boxes are prima
9 matches
Mail list logo
