On 3.5.2016 12:15, Gionatan Danti wrote:
On 02/05/2016 16:32, Mark Mielke wrote:
The WARNING is a cover-your-ass type warning that is showing up
inappropriately for us. It is warning me something that I should already
know, and it is training me to ignore warnings. Thinp doesn't have to be
the answer to everything. It does, however, need to provide a block
device visible to the file system layer, and it isn't invalid for the
file system layer to be able to query about the nature of the block
device, such as "how much space do you *really* have left?"
As this warning appears on snapshots, it is quite annoying in fact. On the
other hand, I fully understand that the developers want to avoid "blind"
overprovisioning. A commmand-line (or a lvm.conf) option to override the
warning would be welcomed, though.
Since number of reports from people who used thin-pool without realizing what
they could do wrong was too high - rather 'dramatic' WARNING approach is
used. Advised usage is with dmeventd & monitoring.
Danger with having 'disable' options like this is many distros do decide
themselves about best defaults for their users, but Ubuntu with their
issue_discards=1 shown us to be more careful as then it's not Ubuntu but lvm2
which is blamed for dataloss.
Options are evaluated...
This seems to be a crux of this debate between you and the other people.
You think the block storage should be as transparent as possible, as if
the storage was not thin. Others, including me, think that this theory
is impractical, as it leads to edge cases where the file system could
choose to fail in a cleaner way, but it gets too far today leading to a
more dangerous failure when it allocates some block, but not some other
block.
...
It is your opinion that extending thin volumes to allow the file system
to have more information is breaking some fundamental law. But, in
practice, this sort of thing is done all of the time. "Size", "Read
only", "Discard/Trim Support", "Physical vs Logical Sector Size", ...
are all information queried from the device, and used by the file
system. If it is a general concept that applies to many different device
targets, and it will help the file system make better and smarter
choices, why *shouldn't* it be communicated? Who decides which ones are
valid and which ones are not?
This seems reasonable. After all, a simple "lsblk" already reports plenty of
information to the upper layer, so adding a "REAL_AVAILABLE_SPACE" info should
not be infeasible.
What's wrong with 'lvs'?
This will give you the available space in thin-pool.
However combining this number with number of free-space in filesystem - that
needs magic.
When you create file with hole in your filesystem - how much free space do you
have ?
If you have 2 filesystem in a single thin-pool - each takes 1/2 ?
It's all about lying....
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
