WARNING: This is the _old_ Lustre wiki, and it is in the process of being retired. The information found here is all likely to be out of date. Please search the new wiki for more up to date information.

Difference between revisions of "Windows Native Client"

From Obsolete Lustre Wiki
Jump to navigationJump to search
Line 86: Line 86:
 
   
 
   
 
Comments from the Meeting:
 
Comments from the Meeting:
   
+
  - eeb: need a clean interface that porting will use.
- eeb: need a clean interface that porting will use.
+
- eeb: need metadata interface that doesn't expose internal stuff to another platform
- eeb: need metadata interface that doesn't expose internal stuff to another platform
+
  - Matt to continue documentation, compile issues, and porting all client components that are common to other platforms (LOV, LDLM, OSC, MDC, LVM, PTLRPC, etc)  Eric  would like to be involved before too much design work is done.
   
+
- Matt has drafted a doc titled gcc_vc.pdf that describes the differences between the gcc and vc compilers, and some proposed solutions.  This was sent to Dan Root, et al,  on Jan 20.  Eric to provide feedback.
- Matt to continue documentation, compile issues, and porting all client components that are common to other platforms (LOV, LDLM, OSC, MDC, LVM, PTLRPC, etc)  Eric  would like to be involved before too much design work is done.
+
  - Alex wants to learn more about Windows. understand simple use cases.  
 
+
  - would OSR implement the file handle stuff?  (do we need to export an MD FID lookup?)
- Matt has drafted a doc titled gcc_vc.pdf that describes the differences between the gcc and vc compilers, and some proposed solutions.  This was sent to Dan Root, et al,  on Jan 20.  Eric to provide feedback.
+
  - Get de-brief from Braam on meeting, have him give direction to Alex on md api
   
+
- Alex to send a list of questions to braam
- Alex wants to learn more about Windows. understand simple use cases.  
+
  - Put a question in doc about what OSR can be doing?
   
+
  - Need an OSR work plan as a result of Braam meeting, so the Lustre team knows all the dependencies and dates on items we're responsible for.
- would OSR implement the file handle stuff?  (do we need to export an MD FID lookup?)
+
  - Do we need an LNET branch?  Give them a snapshot of all of the sources.  Otherwise we don't know what they're implementing to.    Nikita says current client IO can't be used for implementation, as it's not far enough along yet.
   
+
  - Provide branch names: b_winnt _port, HEAD version of LNET.  OSR will need their own private branch when they start to commit code.  Need to sort out branch situation when OSR is ready to check in code.  Their code cannot live in a pubic branch.
- Get de-brief from Braam on meeting, have him give direction to Alex on md api
 
 
 
- Alex to send a list of questions to braam
 
   
 
- Put a question in doc about what OSR can be doing?
 
   
 
- Need an OSR work plan as a result of Braam meeting, so the Lustre team knows all the dependencies and dates on items we're responsible for.
 
   
 
- Do we need an LNET branch?  Give them a snapshot of all of the sources.  Otherwise we don't know what they're implementing to.    Nikita says current client IO can't be used for implementation, as it's not far enough along yet.
 
   
 
- Provide branch names: b_winnt _port, HEAD version of LNET.  OSR will need their own private branch when they start to commit code.  Need to sort out branch situation when OSR is ready to check in code.  Their code cannot live in a pubic branch.
 

Revision as of 06:52, 9 May 2008

Windows/Lustre Native Client Project Information

Links

Windows_Native_Client_Questions

Milestones

- Working Linux Lustre cluster (vmware or otherwise) - Michael MacDonald to assist asap?
- Mounting on windows – requires Matt’s branch to work
- File Browsing
- File I/O
- Integrate with CFS testing
- Performance

Methodology

OSR has a reasonable idea how to get skeleton code together for 1-3, but needs a review of lock revocation and metadata caches before finalizing 3, from someone like Oleg. I expect some assistance from Matt suggesting skeletons etc can help tremendously. Nikita should help architect a skeleton for the file I/O architecture.

Contributors:

OSR

Dan Root – project manager
Tony Mason – design lead, working with Mark
Mark Cariddi - developer

Sun

Bryon Neitzel - Project Manager
Matt – owns libraries, compiler issues, LNET
Nikita – file I/O guidance
Alex - metadata API
Oleg ? – Metadata guidance
Eeb – control landing from the branch
Braam / Eeb – architecture, abstractions

Risks

- all risks are fairly likely and highly disruptive

Loss of CFS attention – CFS project manager
Poorly defined details – CFS documentation team
Out of date libraries – Matt Wu
Compiler issues – Matt Wu
Code base continues to move – CFS development team
Getting it right vs working – Nikita / Oleg 
Landing into 2.0 – Barton

Implementation strategy

OSR will work on skeletons / prototypes and request review of these when ready.

Project management

Frequent status reports with risk update. OSR agreed to weekly status reports and bi-weekly conference calls.

Budget

Peter Braam and Tony were not yet concerned about the budget situation, but the original estimates were too optimistic, in particular because CFS made no progress between October 2007 and April 2008.

Meeting History

Windows Client Meeting, Monday, 2008-05-09

Eric Barton 
Peter Bojanic 
Nikita Danilov
Tony Mason
Bryon Neitzel

Agenda

1. Progress by Mark - need help building any Lustre component?  ldiskfs or LNET?
2. What is next step for OSR after Lustre builds?  Recommendation is to use existing metadata APIs
3. Progress from Matt Wu on compilers and macro issues
4. Status on MD apis from Alex
5. Review developer questions from Google Doc

Windows Client Meeting, Monday, 2008-04-21.

Eric Barton Peter Bojanic Nikita Danilov Alex Tomas Matt Wu Bryon Neitzel

A Google Document was created for questions from the development staff for Braam's meeting with OSR this week. http://docs.google.com/a/lustre.org/Doc?id=d8jgmdp_20fpxwdgb. Alex and Nikita to document questions by Wednesday.

A branch has been created for use by OSR. b_winnt_port branch of lustre-core module (sharing HEAD lnet so far)

Comments from the Meeting:

- eeb: need a clean interface that porting will use.
- eeb: need metadata interface that doesn't expose internal stuff to another platform
- Matt to continue documentation, compile issues, and porting all client components that are common to other platforms (LOV, LDLM, OSC, MDC, LVM, PTLRPC, etc)  Eric  would like to be involved before too much design work is done.
- Matt has drafted a doc titled gcc_vc.pdf that describes the differences between the gcc and vc compilers, and some proposed solutions.  This was sent to Dan Root, et al,  on Jan 20.  Eric to provide feedback.
- Alex wants to learn more about Windows. understand simple use cases. 
- would OSR implement the file handle stuff?  (do we need to export an MD FID lookup?)
- Get de-brief from Braam on meeting, have him give direction to Alex on md api
- Alex to send a list of questions to braam
- Put a question in doc about what OSR can be doing?
- Need an OSR work plan as a result of Braam meeting, so the Lustre team knows all the dependencies and dates on items we're responsible for.
- Do we need an LNET branch?   Give them a snapshot of all of the sources.  Otherwise we don't know what they're implementing to.    Nikita says current client IO can't be used for implementation, as it's not far enough along yet.
- Provide branch names: b_winnt _port, HEAD version of LNET.   OSR will need their own private branch when they start to commit code.   Need to sort out branch situation when OSR is ready to check in code.  Their code cannot live in a pubic branch.