Your search query "linkto:"AfsOsd/Notes"" didn't return any results. Please change some terms and refer to HelpOnSearching for more information.
(!) Consider performing a full-text search with your search terms.

Clear message

Contents

  1. General concepts
    1. Goodies
    2. Working with an AFS+OSD cell
      1. How to migrate data from an OSD
    3. Backup
    4. Priorities and choice of storing OSD
    5. Data held in volumes, DBs etc.
    6. How to upgrade a cell to AFS+OSD
  2. Policies
    1. Open questions
    2. Possible representations for a policy
      1. Disjoint Normal Form
      2. Variable list of rules
      3. Fixed list of predicates
    3. Complex policies
  3. Technical aspects
    1. Performance
    2. Backwards compatibility
  4. Notes on the code (changes)
    1. Link tables
    2. Technical details on ubik databanks
    3. Debugging techniques
  5. Open issues

1. General concepts

1.1. Goodies

1.2. Working with an AFS+OSD cell

The following techniques are only useful when using OSD as a frontend for HSM:

This is how a fileserver and OSD server can share one machine:

The new fs ls subcommand can tell files apart:

1.2.1. How to migrate data from an OSD

  1. set a low write priority to stop fileservers from storing data on the OSD in question 

    osd setosd -wrprior 0

  2. use 

    vos listobj
    to identify the files (by fid) that have data on the OSD

  3. use 

    fs fidreplaceosd
    to move each file's data to another OSD

1.3. Backup

1.4. Priorities and choice of storing OSD

Customizing owner, location:

1.5. Data held in volumes, DBs etc.

1.6. How to upgrade a cell to AFS+OSD

  1. set up OSDDB on the database servers
  2. set up pristine AFS+OSD fileservers + OSDs
  3. move volumes to the AFS+OSD fileservers

    • volserver is supposed to be armed with a -convertvolumes switch for that purpose

    • otherwise, set the osdflag by hand 

      vos setfields <volume> -osd 1

2. Policies

2.1. Open questions

Using the uniquifier field in the vnode:

2.2. Possible representations for a policy

So far we thought of 3 possible notations for policies, each having implications on the overall expressiveness.

2.2.1. Disjoint Normal Form

A policy consists of an arbitrary number of predicates that can be thought of as logically ORed. Evaluation is interrupted as soon as one predicate evaluates to true. Each predicate consists of a number of atomic predicates which are logically ANDed: 

( suffix(".root") ) or ( size > 1M and size < 20M ) or ( size > 20M )

Of course, each case needs to return a definite "answer" to all aspects covered, e.g. 

( suffix(".root") )         => OSD, 1 stripe, 1 site
( size > 1M and size <20M ) => OSD, 1 stripe, 2 sites
( size > 20M )              => OSD, 2 stripes, 1 site
else                        => No Object Storage

the last case being the default. (!) This would need to be set cell-wide.

Discussion
This data model allows for rather efficient evaluation and might easily be represented to an administrator.

2.2.2. Variable list of rules

Like above, the policy consists of a list of predicates. Each can have arbitrary effects on how to store the file's data wrt. the aspects covered by policies (see above). Here too, the predicates must be evaluated in a fixed order. They are limited to logical AND, too. However, evaluation cannot terminate before reaching the end of the list. The default behaviour has to take effect before evaluation starts: 

Default                     => No Object Storage
( suffix(".root") )         => OSD
( size > 1M )               => 2 sites
( size > 20M )              => 1 site, 2 stripes

(this would have much the same effect as the example policy outlines above for DNF).

Discussion
In places, this might have benefits compared to DNF. In human readable form, it would become a sequence of "but if..."s.

2.2.3. Fixed list of predicates

A policy consists of a fixed number of rules that consist of an arbitrary number of atomic predicates that can be linked using AND, OR and NOT and parenthesized. Each corresponds to a certain piece of info about the storing of OSDs: 

OSD           = ( size > 1M or suffix(".root") )
Stripes 1     = true
Stripes 2     = size > 20M
Sites 1       = true
Sites 2       = size < 20M

This appears extremely complex though.

Discussion
Constructing expressions for arbitrary rules is difficult. There are invalid combinations of expressions (e.g., the sets of matches of "Stripes1" and "Stripes2" needs to be disjoint, the matches to "OSD" must superset all others etc.). Apart from printing the logical expressions in semi-mathematical form, it would be difficult to bring this into a human readable form.

2.3. Complex policies

3. Technical aspects

3.1. Performance

3.2. Backwards compatibility

4. Notes on the code (changes)

The explanations are from vol/namei_ops.c. The new format is used as Linktable version 2, with the original format still being supported as version 1. /!\ Does the code need to support legacy link table format? Volumes are incompatible anyway.

4.2. Technical details on ubik databanks

4.3. Debugging techniques

5. Open issues