Re: [ANNOUNCE] Reiser4: Different Transaction Models

[Edward Shishkin <edward.shishkin@gmail.com>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html