Dne 29.7.2013 23:06, Lennart Poettering napsal(a):
On Mon, 29.07.13 16:52, Ric Wheeler (rwhee...@redhat.com) wrote:
Oh, we don't assume it's all ours. We recheck regularly, immediately
before appending to the journal files, of course assuming that we are
not the only writers.
With thinly provisioned storage (or things like btrfs, writeable
snapshots, etc), you will not really ever know how much space is
really there.
Yeah, and that's an API regression.
I guess there is major misunderstanding what is the whole purpose
of thin provisioning.
From this thread one could get the feeling that thinp just complicates
estimations of free space for filesystem :)
But the usage is quite different from the beginning.
- disk space is costly resource
- resizing of filesystem (i.e. ext4) is blocking usage and could be risky.
- lot of filesystems does not support native snapshots.
So thinp is here to help with these things.
- Instead of running multi terrabyte disk arrays when user is only using gigs
of disk space - thinp allows to add storage when needed (so you could
slowly extend your disk arrays with more hw which needs more energy)
- Instead of resizing fs all the time - you create large fs from the beginning
and you let the block layer to resolve magic (at the price of disk
fragmentation)
- Instead of repeatedly writing code for snapshots to every fs - again you let
the block layer to handle it (at the price of less efficient disk space usage).
So the idea that fs would return different number of free space when it's
being run on thinly provisioned device is simply wrong from many points.
And there is no point to support this - since with LVM you could replace
thinp device with linear mirrored device online if that would be needed.
Obviously this would give you very floating results for any stats() functions
you think there should be supported.
Secondly - thinpool is designed to grow - so from which number you would
actually want to estimate the free size - from the current pool size ?
from the free size in whole volume group ? from the size of all attached disks
which could be attached to volume group ?
If you have multiple thin pools in VG - then what do you think the result
value should be here?
And finaly - the snapshot features makes the estimation of free space very
costly operation - if you run multiple snapshots -how do you estimate free
space ? What would be the meaning of this value ?
thinp should work the same. Of course, this requires that the block
layer has to pass more metadata up to the file systems than before, but
there's really nothing intrinsicly evil about that, I mean, it could be
as basic as just passing along a "provisioning perentage" or so which
the fs will simply multiply into the returned values... (Of
course it won't be that simple, but you get the concept...)
Sorry, but the only broken concept I can see here is to allocate
50% of free disk space just because it can be made - disk space is not
local RAM - if the FS tells you it has 1EB doesn't mean the program should
just allocate 500TB for nothing.
In this case admin obviously must properly configure provisioned disk space
for those users who are used to eat every single byte from their fs. Thinp
can't resolve this.
Zdenek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
