David Buckley <dbuckley@xxxxxxxxxxx> 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 WS
> UNMAP request larger than 8192 blocks is received the UNMAP is ignored
> and the result is effectively a WS ZERO request.
That's broken on the filer, then.
> If I'm correct in my understanding, then it seems like the root cause
> of the failures is that the current code assumes a disk will always
> support WS UNMAP requests up to max_ws_blocks and does not account for
> a case where max_unmap_blocks is smaller than max_ws_blocks.
SBC says:
"A MAXIMUM UNMAP LBA COUNT field set to a non-zero value indicates
the maximum number of LBAs that may be unmapped by an UNMAP
command."
"A MAXIMUM WRITE SAME LENGTH field set to a non-zero value indicates
the maximum number of contiguous logical blocks that the device
server allows to be unmapped or written in a single WRITE SAME
command."
I'm confident that our behavior is correct and that the problem is on
the storage side.
The good news is that the new discard code would alleviate your problem
in that (based on what the filer reported in your setup) we'd use UNMAP
to deallocate and WRITE SAME to zero.
--
Martin K. Petersen Oracle Linux Engineering
