Plasma GitLab Archive
Projects Blog Knowledge

Class type Nn_blockmap.blockmap_t


class type blockmap_t = object .. end
block maps are in-memory representation of the per-datastore bitmaps whether blocks are used or free. Changes to block maps are done in a transactional way. One can finally get the accumulated updates of a transaction for writing them out to the db

method active : bool
whether this object refers to an existing row in the datastore table. If the object is inactive, the other methods (except id and identity) will fail with Inactive.
method filled : bool
whether the object is completely filled with data
method id : int
the datastore db table id
method identity : string
This is the blockmap for this datastore identity
method size : int64
Size of the blockmap in blocks
method stats : int64 * int64 * int64
Number of used, transitional, free blocks
method fill_blockmap : int64 -> string -> unit
fill_blockmap index data: Fills the blockmap at index with data, a string consisting of 0 and 1. index must be a multiple of 1024. (This is only allowed once per row for init, and is outside any transaction.)
method fill_from_db : int64 -> int -> unit
fill_from_db index n: Fills the n rows at index from the db (synchronously)
method fill_done : unit -> unit
Set that the map is filled, i.e. filled returns true
method has_free_blocks : bool
whether there are still free blocks
method reserve : int ->
owner -> reserve_info -> triv_range list
reserve n owner ri: finds n free blocks and returns their indices. The reservation is owned by owner, an arbitrary object. Reserved blocks are turned into used blocks at commit time, and freed again on abort. Reserved blocks are implicitly also pinned.

If not enough blocks are free, it is tried to reserve as much as possible. The return value [] means that no more blocks are available.

Requirement: n>0, n<=bmaprowsize

method free : triv_range list -> owner -> unit
free l owner: deallocates these blocks. If they are still only reserved but not yet committed, they keep their reserved status until commit time, and are freed only then. It is allowed to free pinned blocks (but it is not allowed to first free and then pin blocks).
method pin : triv_range list -> owner -> unit
pin l owner: marks these blocks as "to keep" even if a competing transaction frees them. Pinned blocks are a special form of transitional blocks. Basically, a block is pinned when metadata about it is handed out to the client, so the client can be sure that the block keeps it current contents for the time of the pinning. The pinning is removed when the datanode access ticket is cancelled. As long as the pinning lasts the contents of the block are not modified (except in the case when the client requests new blocks and fills them), i.e. pinning prevents that the block is allocated for something else.

It is allowed that several owners pin the same block. In this case the block remains pinned until all owners unpin the block.

Reason 1 for pinning: Transaction X wants to read the block. Transaction Y frees it at the same time, and commits this. Now we have to ensure that X can still read the block although the competing transaction has deleted it.

Reason 2: Transaction X wants to circumvent the security system. X gets a ticket for reading X, frees the block and commits. Now Transaction Y allocates a new block for a different file, and this could be the same block if it were not pinned until the end of the lifetime of the ticket. This would allow a security violation by X because X could read the block just written by Y with its ticket.

Pinned blocks are not entered into the db, so it is not required to get_changes.

method get_changes : owner -> (int64 * string) list
get_changes owner: Returns the changes made by owner. This is a list of database rows (start_index,row_data), to be used for SQL UPDATEs. If owner is unknown, the empty list is returned.

This method must be called before commit, rollback or release.

method commit : owner -> unit
commit owner: commits owner's reservations, and makes them permanent. If there are pinned blocks, these blocks remain pinned for this owner.

If owner is unknown this is a no-op.

method rollback : owner -> unit
rollback owner: unreserves owner's blocks. This does not remove the block pinnings, though.

If owner is unknown this is a no-op.

method release : owner -> unit
release owner: Unpins the blocks of this owner. Effectively, everything about owner is deleted in the blockmap. Note that we have OR logic here: a block is considered as pinned as long as there is at least one pinning owner.
method inactivate : unit -> unit
Sets active to false
method dump : string
Get a dump of the internal state
This web site is published by Informatikbüro Gerd Stolpmann
Powered by Caml