In order to finish the implementation of thin provisioning, we need to add a -drive option to describe how guest discard requests are mapped to host requests.
We have three possibilities: - hide them and make them always succeed - translate them to ANCHOR requests, i.e. mark the space as discarded but keep it allocated (for XFS this is an XFS_IOC_ZERO_RANGE ioctl; for devices we could get a new ioctl in the kernel). - translate them to UNMAP requests, i.e. mark the space as discarded and release it to the filesystem or storage. ANCHOR requests are not yet implemented, but I believe we should plan ahead and develop the feature as if they existed. I'll call these "full", "anchor", "unmap". Kevin pointed out to me that you may need to control these at both the format and protocol levels, which gives 9 possibilities. At the API level there is no problem supporting all of them, but what about the user level? Having two switches makes it complicated to explain the effects, also because: - The protocol setting does not matter with fmt=full; - fmt=unmap/proto=anchor doesn't really make sense. It is the same as what qcow2 currently does, except that you'll also get all possible performance degradations coming from your filesystem. This leaves these five possibilities: fmt=full/proto=full No discard support fmt=anchor/proto=anchor Keeps preallocated files preallocated fmt=anchor/proto=unmap Keeps metadata preallocated fmt=unmap/proto=unmap Fully thin-provisioned fmt=unmap/proto=full Current behavior of qcow2 The current default is full/full, because by default the guest-visible devices do not have discard. Once you enable discard-granularity=512, the default becomes unmap/unmap for raw, and unmap/full for qcow2. When we change the default to discard-granularity=512, the default will have to be changed to full/full or anchor/anchor, with the others selectable from the command-line. Unfortunately, this means there is a backwards-incompatible change for users that are _already_ using discard-granularity=512. So, the first question is what to use for the default. I'm leaning towards anchor/anchor. The other question is: do we need all five? And if so, how to call the options? Here is the best I could come up with: fmt=full/proto=full -drive provision=off fmt=anchor/proto=anchor -drive provision=full fmt=anchor/proto=unmap -drive provision=metadata fmt=unmap/proto=unmap -drive provision=thin fmt=unmap/proto=full -drive provision=reuse Any opinions or improvements on the naming? Paolo
