Re: LVM snapshots
| От | Matt Clark |
|---|---|
| Тема | Re: LVM snapshots |
| Дата | |
| Msg-id | OAEAKHEHCMLBLIDGAFELKEDKDBAA.matt@ymogen.net обсуждение |
| Ответ на | Re: LVM snapshots (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: LVM snapshots
|
| Список | 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,
pluswhatever
hash table overhead there might be. Not much at any rate.
В списке pgsql-admin по дате отправления: