Re: [linux-lvm] Reserve space for specific thin logical volumes

[matthew patton <pattonme@yahoo.com>]

Xen wrote:

> The issue with scripts is that they feel rather vulnerable to  corruption, not being there etc.

Only you are responsible for making sure scripts are available and correctly written.

>  So in that case I suppose that you would want some default, shipped  scripts that come with LVM as
> example for default behaviour and that are  also activated by default?
...
> /usr/share/lvm/scripts/

Heck no to activation. The only path that's correct is that last one. The previously supplied example code should have been more than enough for you to venture out on your own and write custom logic.
 
> Then not even a threshold value needs to be configured.

Nobody else wants your particular logic, run interval, or thresholds. Write your scripts to suck in /etc/sysconfig/lvm/<vgname> or whatever the distro of your choice puts such things.
 
> Yes. One obvious scenario is root on thin.
> It's pretty mandatory for root on thin.

Can you elaborate with an example? Because that's the most dangerous one not to have space fully reserved unless you've established other means to ensure nothing writes to that volume or the writes are very, very well defined. ie. 'yum update' is disabled, nobody has root, the filesystem is mounted RO, etc.
 
>  You cannot set max size for thin snapshots?

And you want to do that to 'root' volumes?!?!
 
> you cannot calculate in advance what can  happen,
> because by design, mayhem should not ensue, but what if your
> predictions are off?

Simple. You don't do stupid things like NOT reserving 100% of space in a thinLV for all root volumes. You buy as many hard drives as necessary so you don't get burned.

> Being able to set a maximum snapshot size before it gets dropped could  be very nice.

Write your own script that queries all volumes, and destroys those that are beyond your high-water mark unless optionally they are "special".

> When free space on thin pool drops below ~120MB

At best your user-space program runs each minute and writing 120MB takes a couple seconds and thus between runs of your 'monitor' you've blown past any chance of taking action.

8TB drives are $250 bucks. buy disk. and buy more disk already and quadruple your notion of reserves. If your workload isn't critical then nobody cares if you blow it sky high and you can do silly things like shaving too close. But I have to ask, to what possible purpose?

> I want the 20GB volume  and the 10GB volumes to be frozen

It takes time for a script log into each KVM domain and issue an fsfreeze or even to just suspend the VM from the hypervisor. Meanwhile writers are potentially writing at several hundred MB per second. You're looking at a massive torrent of write errors.

> much deleted

Sounds like you got all the bits figured out. Write the script and post it to GitHub or PasteBin.


> so that the burden on the administrator is very minimal.

No sysadmin worth a damn is going to not spend a LOT of time thinking whether this sort of thing is even rational, and if so, where they want to draw the line. This sort of behavior doesn't suffer fools gladly nor is it appropriate for people to attempt who don't first know what they are doing. Some parts of Linux/Unix are Experts-Only for a reason.