From: | "Matt Clark" <matt(at)ymogen(dot)net> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ragnar KjÃzrstad <postgres(at)ragnark(dot)vestdata(dot)no>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Murthy Kambhampaty" <murthy(dot)kambhampaty(at)goeci(dot)com>, <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: LVM snapshots |
Date: | 2003-03-17 15:16:19 |
Message-ID: | OAEAKHEHCMLBLIDGAFELKEDKDBAA.matt@ymogen.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
> 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.
> No, you only have to drop the freeze; the original volume is not broken.
Yeah, only the snapshot is damaged
>
> 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, plus whatever
hash table overhead there might be. Not much at any rate.
From | Date | Subject | |
---|---|---|---|
Next Message | Ragnar Kjørstad | 2003-03-17 15:26:30 | Re: LVM snapshots |
Previous Message | Tom Lane | 2003-03-17 14:59:27 | Re: LVM snapshots |