> On Sep 14, 2017, at 2:05 PM, Zdenek Kabelac <zkabe...@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 _______________________________________________ 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/
