<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div>> There is no such thing as WRITE UNAVAILABLE in NVMe.</div><div>Apologize, that is WRITE UNCORRECTABLE. Chapter 3.2.7 of</div><div>NVM Express NVM Command Set Specification 1.0b<br></div><div><br></div><div>> That being siad you still haven't actually explained what problem</div><div>> you're even trying to solve. </div></div><div><br></div>The specific problem is the following: <div>* There is an thinpool over a physical device</div><div>* There are multiple logical volumes over the thin pool</div><div>* Each logical volume has an independent file system and an</div><div>  independent application running over it</div><div>* Each application is potentially allowed to consume the entirety</div><div>  of the disk space - there is no strict size limit for application</div><div>* Applications need to pre-allocate space sometime, for which</div><div>  they use fallocate. Once the operation succeeded, the application</div><div>  assumed the space is guaranteed to be there for it.</div><div>* Since filesystems on the volumes are independent, filesystem</div><div>  level enforcement of size constraints is impossible and the only</div><div>  common level is the thin pool, thus, each fallocate has to find its</div><div>  representation in thin pool one way or another - otherwise you</div><div>  may end up in the situation, where FS thinks it has allocated space</div><div>  but when it tries to actually write it, the thin pool is already</div><div>  exhausted.</div><div>* Hole-Punching fallocate will not reach the thin pool, so the only</div><div>  solution presently is zero-writing pre-allocate.</div><div>* Not all storage devices support zero-writing efficiently - apart</div><div>  from NVMe being or not being capable of doing efficient write</div><div>  zero - changing which is easier said than done, and would take </div><div>  years - there are also other types of storage devices that do not</div><div>  have WRITE ZERO capability in the first place or have it in a</div><div>  peculiar way. And adding custom WRITE ZERO to LVM would be</div><div>  arguably a much bigger hack.</div><div>* Thus, a provisioning block operation allows an interface specific</div><div>  operation that guarantees the presence of the block in the</div><div>  mapped space. LVM Thin-pool itself is the primary target for our</div><div>  use case but the argument is that this operation maps well to</div><div>  other interfaces which allow thinly provisioned units.</div><div><div><div><br clear="all"><div>--Daniil</div></div></div></div></div>