Dne 31.7.2013 10:39, Florian Weimer napsal(a):
On 07/29/2013 08:38 PM, Ric Wheeler wrote:
If application A does a stat or statvfs() call, sees 1GB of space left
and then does a write, we could easily lose that race to any other
application.
If you want to reserve space, you need to grab the space yourself
(always works with a large "write()" but preallocation can also help
without dm-thin).
In order to have it work "always", you'll have to write unpredictable data.
If you write just zeros, the reservation isn't guaranteed if the file system
supports compression.
I'm pretty sure we want a crass layering violation for this one (probably a
new mode flag for fallocate), to ensure proper storage reservation for things
like VM images.
If someone wants to use preallocation - thus always allocate whole space,
than there is no reason to use provisioned devices unless someone want's to
use its snapshot feature (for this there could be probably introduced
something like creation of fully provisioned device) - but then you end-up
with the same problem once you start to use snapshot.
For me this rather looks like misuse of thin provisioning.
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....
Maybe - just an idea - there could be a kernel bit-flag somewhere, which might
tell if the device used by fs is 'fully provisioned' or 'thin provisioned'
(something like rotational/non-rotational) But there is no way to return
information about free disc space - since it's highly subjective value and
moreover very expensive to calculate.
Zdenek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
