Re: [linux-lvm] about the lying nature of thin

[Gionatan Danti]

On 29/04/2016 10:44, Marek Podmaka wrote:

Hello Xen,
Now I'm not sure what your use-case for thin pools is.

I don't see it much useful if the presented space is smaller than
available physical space. In that case I can just use plain LVM with
PV/VG/LV. For snaphosts you don't care much as if the snapshot
overfills, it just becomes invalid, but won't influence the original
LV.



Let me add one important use case: have fast, flexible snapshots.

In the past I used classic LVM to build our virtualization servers, but 
this means I was basically forced to use a separate volume for each VM: 
using a single big volume and filesystem for all the VMs means that, 
while snapshotting it for backup purpose, I/O become VERY slow on ALL 
virtual machines.


On the other hand, thin pools provide much faster snapshots. On the 
latest builds, I begin using a single large thin volume, on top of a 
single large thin pool, to host a single filesystem that can be 
snapshotted with no big slowdown on the I/O part.


I understand that it is a tradeoff - classic LVM mostly provides 
contiguous blocks, so fragmentation remain quite low, while thin 
pools/volumes are much more prone to fragament, but with large enough 
chunks it is not such a big problem.


Regards.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@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/

Re: [linux-lvm] about the lying nature of thin

[Marek Podmaka]

Hello Xen,

Friday, April 29, 2016, 0:37:23, you wrote:

> In practical matters a thin volume only starts to lie when "real space"
> < "virtual space" -- a condition you are normally trying to avoid.

> Thin pools do not lie by default. They lie when they cannot fulfill
> their obligations, and this is precisely the reason for the idea I 
> suggested: to stop the lie, to be honest.

I would say that thin provisioning is designed to lie about the
available space. This is what it was invented for. As long as the used
space (not virtual space) is not greater then real space, everything
is ok. Your analogy with customers still applies and whole IT business
is based on it (over-provisioning home internet connection speed,
"guaranteed" webhosting disk space). It seems to me that disk space
was the last thing to get over- (or thin-) provisioned :)

Now I'm not sure what your use-case for thin pools is.

I don't see it much useful if the presented space is smaller than
available physical space. In that case I can just use plain LVM with
PV/VG/LV. For snaphosts you don't care much as if the snapshot
overfills, it just becomes invalid, but won't influence the original
LV.

But their use case is to simplify the complexity of adding storage.
Traditionally you need to add new physical disks to the storage /
server, add it to LVM as new PV, add this PV to VG, extend LV and
finally extend filesystem. Usually the storage part and server (LVM)
part is done by different people / teams. By using thinp, you create
big enough VG, LV and filesystem. Then as it is needed you just add
physical disks and you're done.

Another benefit is disk space saving. Traditionally you need to have
some reserve as free space in each filesystem for growth. With many
filesystems you just wasted a lot of space. With thinp, this free
space is "shared".

And regarding your other mail about presenting parts / chunks of
blocks from block layer... This is what device mapper (and LVM built
on top of it) does - it takes many parts of many block devices and
creates new linear block device out of them (whether it is stripped
LV, mirrored LV, dm-crypt or just concatenation of 2 disks).

-- 
  bYE, Marki

___
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/