[linux-lvm] Available snapshot chunks known in LVM2

[Jason Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

I am trying to implement a script that will automagically grow a snapshot 
volume if it is getting too full, using 2.4.20-dm-7 and the latest stable 
LVM2 and libdevmapper.

My problem is that the integer percent full value is not precise enough: on 
for example a 100GB volume, those increments of course only tell me my 
snapshot usage down to 1GB, and my ultimate goal is to put off reallocating 
as long as possible, so I need to see this number down to, say, a 100MB 
granularity.  Also, the current implementation rounds down, so 99.97% could 
be interpreted as 1GB free in this example.  So I spent the last couple of 
hours learning LVM code and implementing this change.

My first attempt worked!  But I'm not sure it's the best approach.  Basically 
these are the changes necessary:
In device-mapper:
1) modify struct exception_store to include two new methods; one returns 
chunks used, the other the total chunks
2) implement them in dm-exception-store.c
3) modify snapshot_status() to snprintf the percentage (as original), but to 
append the used and total chunks from the said functions (this is backward 
compatible with current LVM userland functionality)

In LVM2:
1) Change dev_manager_snapshot_percent() to grab the appended "used" and 
"total size" values from dm
2) Modify lv_snapshot_percent() to calculate the percentage instead.  Actually 
when I did it this way, I got a little win because the percentage is an 
actual float, and not a type conversion from the dm's int.  (Although maybe a 
simpler fix would be just to make persistent_percentfull return float like 
any function named "percentfull" should!)
3) Actually at this point, I was log_print()ing for debugging purposes so my 
proof-of-concept script just greps it out of the output at this time.

Thoughts?  IMO, firstly, the percentage full is certainly a number only 
interesting to users (or rather userland), so why is it getting calculated in 
the kernel?  Secondly, my script and any similar daemon, etc. would just be 
pulling the data back out of that fraction anyway to get a clearer picture, 
so why not just return it from the kernel?  Anyway, my changes fixed both 
problems.  I'd be happy to send diffs, BTW.

Thanks.

- -- 
Jason Smith
Open Enterprise Systems
Bangkok, Thailand
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+S6Hfm5qEoSbpT3kRAuQ3AJ9KNw4swX49SFda96gJVT08bChsrgCdFpdb
fVNsVMBkX/yQRuzPhTwaLNA=
=H4M7
-----END PGP SIGNATURE-----