[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-lvm] LVM Snapshots & journal recovery

On Wed, 23 May 2001, Steve Pratt wrote:

> Peter, I fail to see how your proposed method of remapping writes to the
> original to the snapshot volume avoids the synchronous write penalties.

Hmm, I think you are raising many interesting issues.

> For example in your scenario, the filesystem journal itself will have to be
> written to the snapshot volume, so in order to ensure journal consistency
> you will need to write the remapping meta data synchronously with the
> remapped journal chunk or you would not know that the journal had been
> remapped.  Both writes must done synchronously or you have possible
> corruption.

The journal itself really shouldn't be on a snapshotted device - that
makes no sense.

The write operations are now idempotent: there is in fact no need
whatsoever to write anything synchronous since the journal replay will
always get it right.

For writing I believe what I have proposed is vastly superior:
no syncrhonous writes _and_ no copying of blocks.

> In addition to having to do the same number of synchronous writes, you have
> the additional penalty that you mentioned of the sync time when deleting
> the snapshot.  This resyncing also come with a whole new set of consistency
> issues (whole new code path)

It's not an additional penalty at all: this code again is idempotent too.
If it fails you can run it again - I think it has very simple logic but of
course I may be overlooking something.  Before you start the deletion
process the snapshot becomes unusable.  After it has completed the extra
partition becomes superfluous.

Also such a process can run in the background and would copy no more
blocks than doing the writes the other way around.

> Also, you have moved the remapping lookup processing time penalty for reads
> from the snapshot to the original.  I think it is much better to optimize
> the access to the original as opposed to the snapshot for most cases.

This is a serious point: the reads need an indirection.

We did benchmarking of this in SnapFS and the redirection blocks are not
many and are typically cached.  It didn't seem to cost much at all.

What do you think of this?

- Peter -

> Steve
> EVMS Development - http://www.sf.net/projects/evms
> Linux Technology Center - IBM Corporation
> (512) 838-9763  EMAIL: SLPratt US IBM COM
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo vger kernel org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]