Dne 10. 07. 26 v 21:14 Mohamed Eltamawey napsal(a):
Hi,
I'm designing a storage layout for a virtualization framework and want to
sanity-check the approach against a real thin-pool user before I commit to it.
Setup:
- One VG, one thin pool
- A small number of read-only "base image" thin LVs inside the pool
(set with lvchange -pr)
- Per-session thin snapshots of those base images ("writeback" disks) —
each session writes only into its own snapshot, and gets lvremove'd
when the session ends
Questions:
1. Is there any way to mark a thin LV as "low value / freely disposable"
so that pool-level health/monitoring treats a failure on that LV
differently from a failure on the read-only base LV? As far as I can
tell there's no such attribute and tags are the only practical way to
distinguish them for my own tooling — is that right, or is there a
built-in mechanism I'm missing?
Hi
ATM lvm2 supports i.e. 'tags' - so user can 'tag' LVs with some extra info,
and then he can setup 'callback' script that can be called by dmeventd when
thin-pool passes threshold values i.e. 65% 70%...95% 100% (by default
dmevetnd just invokes lvextend - but it can be anything generic...)
Whatever user does at this point is then up to the logic implemneted - user
may i.e. fstrim, then he can try to remove some LVs according to some rules.
Just keep in mind - using thin-pool when it's full - should be avoid - it's
not a 'regular workflow'.
2. If a single snapshot LV is reported as partial/failed by dmeventd,
is it always safe to lvremove -f just that LV without affecting the
pool's metadata health, as long as the pool itself isn't reporting
failed? Or are there edge cases where a single bad snapshot can
still corrupt shared pool metadata?
'single snapshot failed' would mean you would be using 'thick/old' non-thinly
provisioned snapshot - these snapshot are then unrelated to thin-pool - but
using these old snapshot is discouraged - it's efficient compared to thinly
provisioned snapshot.
Thin snapshot however share the very same thin-pool - thin snapshot is just
'thin volume' which is 'prepopulated' by some othen thinLV.
What might be worth for you to investigated is the use of 'external' origins.
You can have 'thin-pool' with 'origin' images and then create 'thins' in
individual thin-pools there thin starts with 'external' origin from other
thin-pool.
This way you can achieve much greater granularity in terms how you distribute
your VG disk space - but it mostly depends on type of workload - so just take
a look if this might be having some added value.
Regards
Zdenek
