balooning/dynamic snapshots?

Right now, one has to specify a snapshot size.

If the snapshot takes more space that one specified with -s (size), that snapshot is automatically dropped, and is no longer usable.

Sometimes, it is just not possible to know beforehand how much data will change, but on the other hand, specifying 100% snapshot size is not possible or hard to estimate.

Is it possible to make a "balooning", or dynamic LVM snapshot? That is, if the snapshot reaches its maximum, it will be automatically resized, provided we still have space on the medium.

Looking at lvm manuals, I didn't see such a feature, and the only possibility seems to be to create a userspace program which would check the status of the snapshots periodically, and resize them if needed - but this seems crude, and may not work sometimes (very loaded system, volumes with a lot of writes etc.).

Tomasz Chmielewski
http://lists.wpkg.org

Yeah, that is something I wanted at one time. In it's absence, I hacked up the following brute-force solution. I don't like the concept, but it works.

        #!/usr/bin/ruby
        
        threshold=80.0
        increase_factor=0.5
        
        IO.popen("/testsuite/ltest-boulder/acceptance/common/timed_run 10 /usr/sbin/lvs") do |f|
          f.each_line do |line|
            j,volume,j,j,size,j,used = line.chomp.split(/\s+/)
            if used.to_f > threshold then
              # by bytes
              #size = eval(size.sub(/G$/, ' * 1024 * 1024 * 1024'))
              re = /([\d\.]+)([GM])/
              md = re.match(size)
              size = md[1]
              units = md[2]
              expand_by = size.to_f * increase_factor
              system("echo \"lv #{volume} was #{size}#{units} big and #{used} full and was expaned +#{expand_by}#{units}\" | mail -s \"snap expanded\" root")
              system("/testsuite/ltest-boulder/acceptance/common/timed_run 60 /usr/sbin/lvextend -L+#{expand_by}#{units} /dev/vg0/#{volume}")
            end
          end
        end

Put it in cron and run at an appropriate frequency.

b.

Ooops. I should have mentioned
that /testsuite/ltest-boulder/acceptance/common/timed_run is simply a wrapper that time-bounds a command. You can disregard it's use at the risk of an lv* command hanging and running forever.

b.

I saw a recent reference on this list to the development of a library for lvm functions. Is this at a point where it could be used for anything useful? I have written a program that calls the lvm programs directly but would prefer to use a library if possible. Even if only some functions are done that might still be helpful.

Thank you.
Ben Scott
[email protected]

The python library I was working on has only gotten so far. It does still rely on the lvm commands, at this point *display gathers information. Due to the lack of response from people here and my OCD oriented tendancies to have it be "right" I've actually only ended up implementing very basic functionality. Right now you can gather information about a pv, vg, or lv. You can run vgcfgbackup, and then you can restore a pv referencing that file, and you can restore a vg and its lvs with the vgcfgrestore command. It also imports data from an XML utility a co-worker wrote so that in a restore environment you can populate the objects without being able to pull their info from the system. (effectively pickling the data, but with xml).

The template for the other functions is there and easy to populate, and the display function might need to be migrated from *display to *s. Unfortunately I got little feed back so this is as far as I've gotten since its all i have to have for the application I'm writing. Long-term I'd like to see a more complete module, but I would need a more detailed understanding of LVM, imo, to do that. And while I keep reading up, I don't know how detailed of an understanding I will ever really have.

-greg

[email protected] wrote on 11/25/2007 11:12:31 PM:

I

prefer

might