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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
