Re: LVM snapshots
От | Ragnar Kjørstad |
---|---|
Тема | Re: LVM snapshots |
Дата | |
Msg-id | 20030317153148.GC23149@vestdata.no обсуждение исходный текст |
Ответ на | Re: LVM snapshots ("Matt Clark" <matt@ymogen.net>) |
Список | pgsql-admin |
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
В списке pgsql-admin по дате отправления: