On Mon, Mar 17, 2003 at 03:16:19PM -0000, Matt Clark wrote:
> > Ah, I see: so while the freeze is on, writes to the frozen volume cost
> > about 3x normal (1 write -> 1 read + 2 writes), but establishing and
> > discontinuing the freeze cost nothing. And if you have a crash the
> > volume is still in the proper state. Good.
>
> I think that should be 1 read + 2 writes for the first write to a given block, but just 1 write from then on.
Ah, the read is needed if you're not writing the full block, right?
Discard my email on this topic, then.
> > I would wonder though about the datastructure that LVM uses to remember
> > which blocks of the frozen volume have been copied (and where) on the
> > snapshot area. I assume this table lives in kernel memory --- what
> > happens if it gets large?
>
> /* copy on write tables in disk format */
> typedef struct lv_COW_table_disk_v1 {
> uint64_t pv_org_number;
> uint64_t pv_org_rsector;
> uint64_t pv_snap_number;
> uint64_t pv_snap_rsector;
> } lv_COW_table_disk_t;
>
> Looks like 256 bytes per disk block. At a default LVM block size of 64KB that's a 4MB table for 1GB of dirty blocks,
pluswhatever
> hash table overhead there might be. Not much at any rate.
I'm confused.
First I thought LVM used 32bit block-numbers.
Second, I thought 4 MB was the default extent-size.
Third, I thought this was a fixed mapping table, not a dynamic table.
I must admint it has been a long time since I read the lvm-source, so I
may have forgotten or they may have changed it.
Is this from LVM1 or LVM2?
Is the COW-table different from the regular LVM mapping table?
--
Ragnar Kjørstad
Zet.no