On Tue, 12 Aug 2008, FUJITA Tomonori wrote:
On Mon, 11 Aug 2008 18:12:08 -0400 (EDT) Mikulas Patocka <mpatocka@xxxxxxxxxx> 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
applies.
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:
http://groups.google.com/group/zumastor/browse_thread/thread/523ee7925add3dfc/a5d26a4b48fd8906?lnk=gst&q=#a5d26a4b48fd8906
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.
--
Steve
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
