All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter J Braam <Peter.Braam@Sun.COM>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] [Fwd: Re: WBC subcomponents.]
Date: Wed, 23 Jan 2008 09:00:36 +0800	[thread overview]
Message-ID: <479691B4.6020004@sun.com> (raw)


Hi Nikita -

This looks excellent, except that I don't feel we have a good basis for 
the estimates yet. 

This has major architectural value as it gives a component breakdown and 
should be recorded as such on the architecture wiki.  When you do these 
component breakdowns it is important to identify what interfaces are 
offered and used by the components (this is the static aspect of the 
interface).  It is also useful to make interaction diagrams showing how 
the components use each other to execute use cases (this is the dynamic 
aspect).

- Peter -

Nikita Danilov wrote:
> Hello,
>
> below is a tentative list of tasks into which WBC effort can be
> sub-divided. I also provided a less exact list for the EPOCH component,
> and an incomplete list for the STL component.
>
> WBC tasks are estimated in lines-of-code with the total of (9100 + 3000)
> LOC, where LOC is a non-comment, non-whitespace line of the source
> file. I believe it is too early to estimate all EPOCH tasks, hopefully
> there will be more clear understanding of the situation during next
> week. I tried to estimate the EPOCH tasks that are absolutely necessary
> during the early stages of WBC development.
>
> Vladimir is the best person to complete the list of STL tasks,
> together with the estimations.
>
> C-* tasks are for the client, S-* tasks are for the server.
>
> ESTIMATION
>
>                      scope                                                effort
>                                                                              loc
> WBC
>
>     C-VFS-MM         integration with vfs: inodes, dentries, memory         2500
>                      pressure. Executing operation effects locally.
>
>     C-ops-caching    tracking operations: list vs. fragments. Tracking      2500
>                      dependencies.
>
>     C-write-out      policy deciding when to write-out cached state         1000
>                      updates, and with what granularity: age, amount,
>                      max-in-flight
>
>     C-dir-pages      caching of directory pages and using them for local    1000
>                      lookups
>
>     C-new-files      creation of new files locally                           200
>
>     C-new-objects    creation of new objects locally                         200
>
>     C-DLM            invoking reintegration on a lock cancel, lock           200
>                      weighting
>
>     C-data           dependencies between cached data and meta-data          200
>
>     C-IO             switching between whole-file mds-based locking and      250
>                      extent locking
>
>     C-grants         unified resource range leasing mechanism                250
>
>     S-grants         unified resource range leasing mechanism                250
>
>     C-misc           sync, fsync, compatibility flag, mount option           200
>
>     S-misc           compatibility flags                                     100
>
> STL
>
>     C-policy         track usage statistics and use them to decide when to
>                      ask for an STL
>
>     S-policy         track usage statistics and use them to decide when to
>                      grant an STL
>
> EPOCHS
>
>     formalization    formal reintegration model with "proofs" of recovery
>                      correctness and concurrency control description
>
>     C-reintegration  reintegration, including concurrency control,          1000
>                      integration with ptlrpc
>
>     S-compound       implementation of the compound operations on           1000
>                      the server
>
>     S-reintegration  reintegration of batches on the server, thread         1000
>                      scheduling
>
>     S-undo           keeping undo logs
>
>     S-cuts           implementation of the CUTs algorithm
>
>     C-gc             garbage collection: when to discard cached batches
>
>     S-gc             garbage collection: when to discard undo logs
>
>     C-recovery       replay, including optional optimistic "pre-replay"
>
>     S-recovery-0     roll-back of the uncommitted epochs
>
>     S-recovery-1     roll-forward from the clients
>
> EXTERNAL DEPENDENCIES
>
>     ost-fid          ost understanding fids, and granting fid sequences
>                      to the clients
> Nikita.
>   
</div>

                 reply	other threads:[~2008-01-23  1:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=479691B4.6020004@sun.com \
    --to=peter.braam@sun.com \
    --cc=lustre-devel@lists.lustre.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.