On 02/05/2016 16:32, Mark Mielke wrote:
2) Frequent snapshots. In many of our use cases, we may take snapshots every 15 minutes, every hour, and every day, keeping 3 or more of each. If this storage had to be allocated in full, this amounts to at least 10X the storage cost. Using snapshots, and understanding the rate of churn, we can use closer to 1X or 2X the storage overhead, instead of 10X the storage overhead. 3) Snapshot as a means of achieving a consistent backup at low cost of outage or storage overhead. If we "quiesce" the application (flush buffers, put new requests on hold, etc.) take the snapshot, and then "resume" the application, this can be achieved in a matter of seconds or less. Then, we can mount the snapshot at a separate mount point and proceed with a more intensive backup process against a particular consistent point-in-time. This can be fast and require closer to 1X the storage overhead, instead of 2X the storage overhead.
This is exactly my main use case.
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.
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.
I didn't disagree with all of your points. But, enough of them seemed to be directly contradicting my perspective on the matter that I felt it important to respond to them.
Thinp really is a wonderful piece of technology, and I really thanks the developer for it.
-- Mark Mielke <mark.mielke@gmail.com <mailto:mark.mielke@gmail.com>> _______________________________________________ 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/
-- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8 _______________________________________________ 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/
