On 10/18/2014 08:53 PM, Dušan Čolić wrote:
AFAIK other FSes using COW method of allocation don't just mark the
old blocks for discarding but offer a feature of snapshots, they keep
the old block that were changed after some snapshot point and they can
easily transfer through multiple snapshots.
To implement snapshots in R4 would this have to be done or something more:
1. Change allocator logic to mark every changed block not dirty but
with last snapshot identifier. If there's no last snapshot mark it
dirty. If snapshot is deleted delete its blocks if there aren't any
younger snapshots referencing that data;
2. Make interface (sys?) to show and manipulate (create, make active,
delete, show status) snapshot points.
I've worked out this ~6 months ago..
From my standpoint, the feature of snapshots includes the following
notions:
1. Chronology is a set H of linearly ordered elements (called
times-tamps) with
the following operations:
H.create timestamp() — create a new timestamp, add it to H and return it;
H.remove timestamp() — remove a specified timestamp from H;
H.list() — return a list of all timestamps of H.
and the following property: every new timestamp added by H.create
timestamp() is the
largest element of H at the moment of addition.
2. A (simple) file system volume C is said to possess a feature of (local)
snapshots, iff C, in addition, possesses the following parameters and
virtual methods:
C.init_snapshots() — create a timestamp in the local chronology to refer
the initial
"version" of the volume. Return this timestamp;
C.create_snapshot() — create a shapshot of C, store it, and return a
unique times-
tamp of the snapshot in the local chronology of C;
C.restore_snapshot() — deploy a specified snapshot of C;
C.delete_snapshot() — delete a specified snapshot of C.
3. Snapshot points could eventually have some treelike structure and
get pretty complex but there had to be made some way to calculate
space occupied by every snapshot.
First, we should decide what technique we'll choose for our snapshots.
Assume, that this is a fashionable technique of reference counters (like in
ZFS, etc). If so, than we'll need to use the write-anywhere transaction
model (txmod=wa), because overwrites (txmod=journal) will spoil our
snapshots.
Next, we'll need to adjust the technique if lazy reference counters
(invented
by Ohad Rodeh) to the bottom-top process of the storage tree balancing.
With the upgraded algorithmic base I suggest to implement the read-only
snapshots of simple reiser4 volumes. Once it works, we can easily implement
writable and super-writable snapshots.
Read-only snapshots will require to maintain a list (array) of storage
tree roots
(AKA chronology defined above). Also we'll need a new format of tree nodes
(node41), which includes the reference counter (8 bytes).
Basically, that's all..
Is this all possible without disk format change?
You don't need to worry about this.
We have worked out the backward compatible development model for Reiser4.
(format 4.X.Y will be released).
Edward.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
