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

Re: [dm-devel] [PATCH RFC] dm snapshot: shared exception store

On Tue, 12 Aug 2008, FUJITA Tomonori wrote:
On Mon, 11 Aug 2008 18:12:08 -0400 (EDT) Mikulas Patocka <mpatocka redhat com> wrote:
- drop that limitation on maximum 64 snapshots. If we are going to
redesign it, we should design it without such a limit, so that we wouldn't
have to redesign it again (why we need more than 64 --- for example to
take periodic snapshots every few minutes to record system activity). The
limit on number of snapshots can be dropped if we index b-tree nodes by a
key that contains chunk number and range of snapshot numbers where this

Unfortunately it's the limitation of the current b-tree
format. As far as I know, there is no code that we can use, which
supports unlimited and writable snapshot.

I've recently worked on the limit of 64 snapshots and the storage cost of 2x64bits per modified chunk. A btree format that fixes these two issue is described in this post: http://lwn.net/Articles/288896/ If you have the time / energy, I believe that this format will work well and be simple and elegant. I can't speak for Daniel Phillips, but I suspect he is concentrating on tux3 and not on getting this format into Zumastor.

If you don't want to implement "versioned pointers," an earlier format
change is implemented as a patch against Zumastor here:
It removes the 64 snapshot limit and reduces the meta-data storage requirements, but does not support snapshots of snapshots. This patch has undergone reasonable testing and can be considered beta level code.

With both of these formats, in the context of the Zumastor codebase, the number of snapshots is limited by a requirement that all metadata about a specific chunk fit within a single btree node. This limits the number of snapshots to approximately a quarter the chunk size. i.e. 4k chunks would support approximately 500 snapshots. Removing that restriction would increase the number of supported snapshots by a factor of eight, at which point the next restriction
is encountered.

- deleting the snapshot --- this needs to walk the whole b-tree --- it is
slow. Keeping another b-tree of chunks belonging to the given snapshot
would be overkill. I think the best solution would be to split the device
into large areas and use per-snapshot bitmap that says if the snapshot has
some exceptions allocated in the pertaining area (similar to the
dirty-bitmap of raid1). For short lived snapshots this will save walking
the b-tree. For long-lived snapshots there is no help to speed it up...
But delete performance is not that critical anyway because deleting can be
done asynchronously without user waiting for it.

I don't know if it would be useful for your port, but there are some
patches floating around the Zumastor mailing list that implement
background delete.  They're not production ready but are a good start on
the implementation.


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