57b47f209f
When regular lvols are created, their size is rounded up to the next cluster boundary. This is not acceptable for esnap clones as this means that the clone may be silently grown larger than external snapshot. This can cause a variety of problems for the consumer of an esnap clone lvol. While the better long-term solution is to allow lvol sizes to fall on any block boundary, the implementation of that needs to be suprisingly complex to support creation and deletion of snapshots and clones of esnap clones, inflation, and backward compatibility. For now, it is best to put in a restriction on the esnap clone size during creation so as to not hit problems long after creation. Since lvols are generally expected to be large relative to the cluster size, it is somewhat unlikely that this restriction will be a significant limitation. Signed-off-by: Mike Gerdts <mgerdts@nvidia.com> Change-Id: Id7a628f852a40c8ec2b7146504183943d723deba Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/17607 Reviewed-by: Ben Walker <benjamin.walker@intel.com> Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Community-CI: Mellanox Build Bot Reviewed-by: Jim Harris <james.r.harris@intel.com> |
||
|---|---|---|
| .. | ||
| include | ||
| lib | ||
| .gitignore | ||
| Makefile | ||
| unittest.sh | ||