Re: Reserve space for specific thin logical volumes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jonathan,

Il 13-09-2017 01:25 Brassow Jonathan ha scritto:
Hi,

I’m the manager of the LVM/DM team here at Red Hat.  Let me thank
those of you who have taken the time to share how we might improve LVM
thin-provisioning.  We really do appreciate it and you ideas are
welcome.

I see merit in the ideas you’ve presented and if I’ve got it right,
there are two main ones:
1) don’t allow creation of new thinLVs or snapshots in a pool that is
beyond a certain threshold
2) allow users to reserve some space for critical volumes when a
threshold is reached

I believe that #1 is already handled, are you looking for anything else?

Yeah, this is coverd by the appropriate use of snapshot_autoextend_percent. I did not realized that, thanks to Zdenek for pointing me to the right direction.

#2 doesn’t seem crazy hard to implement - even in script form.  In
RHEL7.4 (upstream = "Version 2.02.169 - 28th March 2017”), we
introduced the lvm.conf:dmeventd/thin_command setting.  You can run
anything you want through a script.  Right now, it is set to do
lvextend in an attempt to add more space to a filling thin-pool.
However, you don’t need to be so limited.  I imagine the following:
- Add a “critical” tag to all thinLVs that are very important:
	# lvchange --addtag critical vg/thinLV
- Create script that is called by thin_command, it should:
- check if a threshold is reached (i.e. your reserved space) and if so,
- report all lvs associated with the thin-pool that are NOT critical:
# lvs -o name --noheadings --select 'lv_tags!=critical && pool_lv=thin-pool’ vg - run <command> on those non-critical volumes, where <command> could be:
	# fsfreeze <mnt_point>

The above should have the result you want - essentially locking out
all non-critical file systems.  The admin can easily turn them back on
via fsfreeze one-by-one as they resolve the critical lack of space.
If you find this too heavy-handed, perhaps try something else for
<command> instead first.

Very good suggestion. Actually, fsfreeze should works without too much drama.

If the above is sufficient, then great.  If you’d like to see
something like this added to the LVM repo, then you can simply reply
here with ‘yes’ and maybe provide a sentence of what the scenario is
that it would solve.  (I know there are already some listed in this
thread, but I’m wondering about those folks that think the script is
insufficient and believe this should be more standard.)

Yes, surely.

The combination of #1 and #2 should give the desired outcome (I quickly tested it and I found no evident problems).

Jonathan, Zdeneck, thanks you very much.

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




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux