Searched hist:aeae6079b49631c133c2e6f0d0454e32614a40a4 (Results 1 – 2 of 2) sorted by relevance
| /freebsd/share/man/man4/ |
| H A D | nvd.4 | diff aeae6079b49631c133c2e6f0d0454e32614a40a4 Fri Jan 29 00:15:14 CET 2016 Jim Harris <jimharris@FreeBSD.org> nvd: add hw.nvd.delete_max tunable
The NVMe specification does not define a maximum or optimal delete
size, so technically max delete size is min(full size of namespace,
2^32 - 1 LBAs). A single delete operation for a multi-TB NVMe
namespace though may take much longer to complete than the nvme(4)
I/O timeout period. So choose a sensible default here that is still
suitably large to minimize the number of overall delete operations.
This also fixes possible uint32_t overflow on initial TRIM operation
for zpool create operations for NVMe namespaces with >4G LBAs.
MFC after: 3 days
Sponsored by: Intel
|
| /freebsd/sys/dev/nvd/ |
| H A D | nvd.c | diff aeae6079b49631c133c2e6f0d0454e32614a40a4 Fri Jan 29 00:15:14 CET 2016 Jim Harris <jimharris@FreeBSD.org> nvd: add hw.nvd.delete_max tunable
The NVMe specification does not define a maximum or optimal delete
size, so technically max delete size is min(full size of namespace,
2^32 - 1 LBAs). A single delete operation for a multi-TB NVMe
namespace though may take much longer to complete than the nvme(4)
I/O timeout period. So choose a sensible default here that is still
suitably large to minimize the number of overall delete operations.
This also fixes possible uint32_t overflow on initial TRIM operation
for zpool create operations for NVMe namespaces with >4G LBAs.
MFC after: 3 days
Sponsored by: Intel
|