Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning

[Tom Coughlan]

On Wed, 2013-07-31 at 11:52 +0200, Zdenek Kabelac wrote:
...
> ThinP should be configured in a way that admin is able to extend pool to 
> honour promised space if really needed. It's not a good idea, to provision 1EB 
> if you have at most just 1TB disk and then you expect you will have no 
> problems when someone fallocate() 500TB.
> 
> I.e. if someone is using  iSCSI disc array with 'hw' thin provisioning 
> support, there is no scsi command to provision space - it's admin's work to 
> ensure there is enough disc space to keep up with user demands....

Oops, Zdenek is likely repeating a mis-statement I made about the SCSI
Standard on a call yesterday. I just checked and I was wrong - the
latest draft of the Standard does provide a way to pre-provision space.
Sorry - I should have checked before speaking. 

In March 2010 the SCSI committee added the concept of "anchored thin
provisioning" to the (proposed) SCSI Block Commands – 3 (SBC-3)
Standard. This allows a logical block to be in one of three states:
mapped, deallocated, or anchored.  A write command that specifies an
anchored LBA does not require allocation of additional LBA mapping
resources for that LBA. A write command that specifies a deallocated LBA
may require allocation of LBA mapping resources.

This change was proposed by David Black from EMC. The justification is
reflects our discussion:  

"There is extensive experience with this sort of resource preallocation
mechanism in filesystems, as most physical filesystems are effectively
thin provisioned courtesy of the way that file space allocation works.
In that domain, this sort of preallocation mechanism is useful and used
selectively (e.g., the fallocate() primitive in Linux and Unix systems).
In this context, SCSI anchored functionality can be viewed as extending
filesystem notions of preallocation down to include SCSI thin
provisioning.".

So, 1) others have seen the need for pre-allocation in thinp
environments, 2) hardware will eventually show up that implements it, 3)
it appears as though the extension to fallocate that Mike suggested is
worth investigating, 4) if we do this, we will want to add the concept
to LVM thinp, and 5) to the plumbing in Linux SCSI so we can pass it to
capable hardware. 

Tom