[linux-lvm] thin handling of available space

[Gionatan Danti]

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 at gmail.com <mailto:mark.mielke at gmail.com>>
>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm at 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 at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8