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 по дате отправления: