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

[Brassow Jonathan <jbrassow@redhat.com>]

> On Sep 14, 2017, at 2:05 PM, Zdenek Kabelac <zkabelac@redhat.com> wrote:
> 
>> 
>>       2) I would freeze non-critical volumes ( I do not write to snapshots so that is no issue ) when critical volumes reached safety threshold in free space ( I would do this in-kernel if I could ) ( But Freezing In User-Space is almost the same ).
> 
> There are lots of troubles when you have freezed filesystems present in your machine fs tree... -  if you know all connections and restrictions - it can be 'possibly' useful - but I can't imagine this being useful in generic case...
> 
> And more for your thinking -
> 
> If you have pressure on provisioning caused by disk-load on one of your 'critical' volumes this FS 'freezeing' scripting will 'buy' you only couple seconds (depends how fast drives you have and how big thresholds you will use) and you are in the 'exact' same situation - expect now you have  system in bigger troubles - and you already might have freezed other systems apps by having them accessing your 'low-prio' volumes....
> 
> And how you will be solving 'unfreezing' in cases thin-pool usage drops down is also pretty interesting topic on its own...
> 
> I need to wish good luck when you will be testing and developing all this machinery.

Our general philosophy is, don’t do anything that will corrupt user data.  After that, the LVM team wants to put in place the best possible solutions for a generic user set.  When it comes to thin-provisioning, the best possible thing we can do that we are certain will not corrupt/loose data and is least likely to cause unintended consequences, is to try to grow the thin-pool.  If we are unable to grow and the thin-pool is filling up, it is really hard to “do the right thing”.

There are many solutions that could work - unique to every workload and different user.  It is really hard for us to advocate for one of these unique solutions that may work for a particular user, because it may work very badly for the next well-intentioned googler.

We’ve tried to strike a balance of doing the things that are knowably correct and getting 99% of the problems solved, and making the user aware of the remaining problems (like 100% full thin-provisioning) while providing them the tools (like the ‘thin_command’ setting) so they can solve the remaining case in the way that is best for them.

We probably won’t be able to provide any highly refined scripts that users can just plug in for the behavior they want, since they are often so highly specific to each customer.  However, I think it will be useful to try to create better tools so that users can more easily get the behavior they want.  We want to travel as much distance toward the user as possible and make things as usable as we can for them.  From this discussion, we have uncovered a handful of useful ideas (e.g. this bug that Zdenek filed: https://bugzilla.redhat.com/show_bug.cgi?id=1491609) that will make more robust scripts possible.  We are also enhancing our reporting tools so users can better sort through LVM information and take action.  Again, this is in direct response to the feedback we’ve gotten here.

Thanks,
 brassow