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

Re: [dm-devel] Recommendations for cascaded snapshots



On Oct 01, 2006, at 17:09:21, Alasdair G Kergon wrote:
On Sun, Oct 01, 2006 at 03:12:01PM -0400, Kyle Moffett wrote:
Another quickie question: How can I measure the current %use of a given snapshot device?

lvs -o snap_percent vgname/lvname
(see man page for formatting options to control output units & suppress headings etc.)

Ok; this works for in-LVM snapshots; what if my blockdev isn't actually an LVM device? I'd like to be able to just run some command on /dev/mapper/whatever or even /dev/sdXY that happens to contain my "SnAp" exception table and get an answer from that. If such a tool doesn't exist; I'll probably just read the LVM sources and write one myself but I'd rather not do that if a preexisting solution exists.

My first "solution" was to use stacked snapshots such that the

See the list archives for the thread last week. I'll review the concept & initial code later this week. [see LVM2/lib/report/ columns.h in the source tree for the definitive list of fields; we should probably fix the tools to display the list that got compiled in.]

This looks interesting; this would mean I could just create all the snapshots sequentially and rely on the DM-snapshot code to do the right thing. I suppose the one issue is that the all-in-kernel approach is still horrendously pre-alpha. I've got time constraints so I'm more curious what the present performance disadvantages are to managing the stacking in userspace (using code I've mostly written and partially tested already, and with the exception of the merging, of course).

First of all, it doesn't seem possible to merge two snapshots together

Mark has code to do this for read-only origins (originally implemented in
userspace).

Oh? Do you have a link I could go peek at? My "origin" would be effectively read-only by the time I try to do any merges so an all- userspace solution would be very easy for me to safely implement. It also makes the thread very easy to control CPU and IO usage using traditional process-management tools.

Also, is it possible to mark a DM blockdev as "read-only" so that attempts to mount it read-write or even write to it directly would fail? I _think_ I saw something going via LVM; but I haven't been able to find a simple direct userspace tool to do that. If it's possible but such a tool doesn't exist then I'll probably just write one.

I realize there are a number of advantages to doing everything through the LVM interface but I like to have a manual fallback for when the excrement hits the impeller, especially on beta software like this.

but I couldn't determine how stable it was or whether or not it applied to recent kernels.

I'm part-way through integrating it. Once the snapshot concurrent read/write bug fix is finally sorted out, it shouldn't take long.

Hmm, ok, thanks for the reply. When you get it working do you have a git tree or quilt patchset I could start testing with? Also, I'm curious about the "concurrent read/write bug"; do you have a message- id or reference of some kind for that?

Thanks for all your help!

Cheers,
Kyle Moffett



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