Re: Novice question

Re: Novice question

[Nate Diller]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

Hi Jagannadha

I understand that the terminology in Reiser4 is rather difficult to 
understand, even when you are reading the source code and comments.  A 
while ago I put together a glossary of terms which is still very much a 
work in progress.  I have included the latest version of it, in case you 
find it helpful.  If you or someone else on this list has additions or 
corrections, feel free to let me know.  I guess eventually we should 
post this to the web site too...

heh, I just read through it again and it's more rough and incomplete 
than I thought.  Maybe some of the guys who know this code better could 
answer some of the outstanding questions in it?

NATE

[-- Attachment #2: reiser4glossary --]
[-- Type: text/plain, Size: 3754 bytes --]

Reiser4 Glossary

Node:  Implemented as a file system block, the basic unit for the tree.  On x86, a node is 4KiB in size, however, there is no restriction
on it's size (is that true?), and there is no design restriction enforcing fixed-size nodes.  Each node has
a search plugin, so that node layouts are not written into the reiser4 spec.  *Compression can occur for unformatted nodes?  How?  I had
assumed it was done item-by-item as part of the item plugin.  Encryption too?  @#$%  Ok, they also appear to have their own search
methods too, even though all they have to do is find the item and invoke it's plugin.  What does an unformatted node's search plugin do?*

Object:  A logical entity at the semantic layer, such as a file or a directory.  This can be split into multiple pieces in the tree, as
determined by the storage layer, however, at the semantic layer, an object acts as though it is a single unified entity.  Each object has
a semantic plugin, such as a file or directory plugin (or both???), controlling how it is manipulated.  Objects are connected to each
other by directories, to form a graph.  *Is this entirely accurate?  Directories are mappings, and a mapping is more specific than the
vertex of a graph.  Even for a directed graph, there is no name to any vertex.  Also, what about lists?  Could a directory plugin be
written that has list semantics, including insert/delete, and ranges?*

Item:  The container object for the storage layer, it cannot span nodes.  In practice, they only hold data from one object, but the spec
does not limit items in this way.  Items can grow or shrink as necessary, and may be split or joined, but all of this behavior is
governed by the item plugin, not the tree's balancing code.  {Does the item plugin do anything other than balancing?}

Unit:  An indivisible piece of information.  A unit is a construct of a particular item plugin, so the balancing code never deals with
units directly, only that item's plugin does.  Nor is an item required to implement this, it could simply declare itself indivisible,
however, since items cannot span nodes, this would limit the size of it's contents.

Key:  Every item has exactly one key, which is it's non-unique identifier within the tree.  When the semantic layer wants to store data,
it asks the key assignment plugin for a key, and then invokes the storage layer to associate the data with that key.  Likewise to
retrieve data, the semantic layer gets the key it needs from supplying the key assignment plugin with the identifying information that
was supplied at creation time, and the appropriate key is generated.  The only function that might ever change the key for any data is a
repacker function, not yet written, that optimizes file placement in the tree (not just on disk, but tree locality).  The default
plugin's key is composed of two parts.  The first part references an object by it's objectID, and the second part an offset within that
object. *How are these parts distinguished?  If the second half of the key is an offset, then files must be stored contiguously (in tree
order, and in disk order if the repacker has finished).  How can the second part refer to an offset if an object can have data added
or removed from the middle?*

ObjectID:  The unique identifier for each object.

File:  The file object is a sequence of bytes, manipulated by it's plugin methods.  The file plugin is specified by the stat data object
which also holds other file metadata.

Directory:  Directory objects map a set of strings (names) to their corresponding objectID(?).  The hash plugin is specified per
directory plugin.  *Any connection with files (duality)?  How does the item plugin associated with entries know how to balance them?*

Re: Novice question

[Nikita Danilov]

Nate Diller <ndiller@namesys.com> writes:

>
> Node: Implemented as a file system block, the basic unit for the tree.
> On x86, a node is 4KiB in size, however, there is no restriction on
> it's size (is that true?), and there is no design restriction

In current implementation node is bound to of the same size as page in
the page cache on the underlying platform, but this is not design
restriction.

>

[...]

>
> Key: Every item has exactly one key, which is it's non-unique
> identifier within the tree.  When the semantic layer wants to store

Every _unit_ has exactly one key. Item spans key-range covered by its
units.

> data, it asks the key assignment plugin for a key, and then invokes

there is no key assignment plugin... yet. Key assignment is hard-coded.

[...]

>
> Directory: Directory objects map a set of strings (names) to their
> corresponding objectID(?).  The hash plugin is specified per directory

Hash plugin is specified for one particular instance of directory
plugin: hashed-directory plugin. Other directory plugins may use
completely different indexing techniques.

Nikita.

Re: Novice question

[Vladimir Saveliev]

Hello

On Thu, 2005-04-07 at 02:07, Nikita Danilov wrote:
> Nate Diller <ndiller@namesys.com> writes:
> 
> >
> > Node: Implemented as a file system block, the basic unit for the tree.
> > On x86, a node is 4KiB in size, however, there is no restriction on
> > it's size (is that true?), and there is no design restriction
> 
> In current implementation node is bound to of the same size as page in
> the page cache on the underlying platform, but this is not design
> restriction.
> 
> >
> 
> [...]
> 
> >
> > Key: Every item has exactly one key, which is it's non-unique
> > identifier within the tree.  When the semantic layer wants to store
> 
> Every _unit_ has exactly one key. Item spans key-range covered by its
> units.
> 

This is not true for units of extent items.

> > data, it asks the key assignment plugin for a key, and then invokes
> 
> there is no key assignment plugin... yet. Key assignment is hard-coded.
> 
> [...]
> 
> >
> > Directory: Directory objects map a set of strings (names) to their
> > corresponding objectID(?).  The hash plugin is specified per directory
> 
> Hash plugin is specified for one particular instance of directory
> plugin: hashed-directory plugin. Other directory plugins may use
> completely different indexing techniques.
> 
> Nikita.
> 

Novice question

[Jagannadha Bhattu]

Which is the best way to start learing reiserfs internals, so that I
can contribute to it. If there are any suggestions on good books to
read, please let me know.

Thanks
Jagannadha.

Re: Novice question

[Vladimir Saveliev]

Hello

On Wed, 2005-04-06 at 17:19, Jagannadha Bhattu wrote:
> Which is the best way to start learing reiserfs internals,

the best way is to look at source code.
fill free to ask questions about it.
You can also take a look at namesys.com

>  so that I
> can contribute to it. If there are any suggestions on good books to
> read, please let me know.
> 


> Thanks
> Jagannadha.
> 

Re: Novice question

[Hans Reiser]

Jagannadha Bhattu wrote:

>Which is the best way to start learing reiserfs internals, so that I
>can contribute to it. If there are any suggestions on good books to
>read, please let me know.
>
>Thanks
>Jagannadha.
>
>
>  
>
website and then source code are the way.  Source code is well commented.

Hans