[gfs-wg] Re: Grid File System Architecture Workbook

Tue May 24 21:22:45 CDT 2005

Hi Arun,

One of reasons that I suggest to remove the section 4.5 is I do not
think 'GFS Server' is really required to realize Grid file system.
Instead, client-side library (or service) can provide required
functionalities for the GFS Server including accessing namespace,
accessing file data, replicating file data, and updating namespace.
This is true for Gfarm and probably EGEE.

A case that we need such 'GFS Server' is to export Grid file system
(or translate protocols) to legacy clients such as NFS, CIFS, FTP, and
HTTP clients.  On the other hand, in this case, 'GFS Server' is not
really a GFS Server but a proxy server that can be set up in several
locations.  One of such scenarios are written in [1].

[1] Leo Luan and Ted Anderson, "Grid Namespace for Files", GGF working
    draft, GGF8, 2003
    https://forge.gridforum.org/projects/gfs-wg/document/Grid_Namespace_for_Files/en/1

In either case, I do not think it is better to describe and introduce
'GFS Server' in this document.  Rather, I suggest to summarize
requirements and expectation from vendors and users for Grid file
system since this document already includes them.

Thanks,
Osamu

>> On Wed, 18 May 2005 12:10:45 -0700, "Arun swaran Jagatheesan" <arun at sdsc.edu> said:

>> There is no Telecon today. There will be one next week - I am trying to
>> have the telecon bi-weekly. As part of this week's GGF-GFS (home) work,
>> we will continue with our discussions - It is a progress that we are
>> discussing this abstract document before we proceed with the technical
>> details (which could need more discussions). We can further continue
>> these discussions over the mail and use the Telecon to confirm a
>> resolution on how to proceed further.

>> Here are the issues raised for discussion:

>>  - Overloaded usage of the word "Namespace":
>> Osamu has mentioned about the usage of the terms like "logical
>> namespace, logical resource namespace, federated logical resource
>> namespace, .... etc.".
>> RESOLUTION: I will find out all the occurrences of the word "namespace"
>> and make sure they are not overloaded. I agree with Osamu that the
>> document and WG has to be consistent in naming. It is possible that we
>> are used to different connotations for the same word - so this also will
>> be a good exercise. The Glossary could help us all to be on the same
>> page.  Let me know if there is any suggestions or comments on the
>> existing Glossary.

>>  - Non-Webservice client (Figure 4, page 9 and 5.2.7)
>> As part of the Architecture three forms of clients are suggested (Figure
>> 4). The GFS-WG currently works only on standardizing the services-based
>> client. One issue that was raised in last week's telecon and also in
>> Osamu's mail is the use of non-Webservice based client software or
>> protocol. We need to discuss this.
>> My opinion: There is no resolution yet from a WG-community perspective.
>> I am providing my opinion here based on my interaction with our users.
>> Currently, most users need the GFS-like system. It will be a restriction
>> to enforce the users (of any vendor implementation) to use only
>> service-based interface. The GFS is a good thing - but it should NOT be
>> about just one interface. Users should have the flexibility to take
>> advantage of the GFS from any interface. Figure 4 mentions the
>> possibility of using the GFS from existing FS-client protocols,
>> WS-Service client protocol and a new GFS-non-WS-client protocol. Our WG
>> currently is working only on the WS-Service client protocol. If and how
>> this new GFS-non-WS client protocol can be made a recommendation might
>> have to be discussed.

>>  - Functionality of the GFS Server (Figure 4, page 9)
>> Yes it was left abstract - but seems to be too abstract. The GFS Server
>> services the GFS-related requests from the GFS clients. As of now we
>> expect it to respond only to XML based requests. This server has access
>> to the metadata information from GFS-namespace and mapping to the
>> Traditional FS namespace (where the data is really located). It can also
>> initiate the operations that can be performed on the GFS-Namespace.
>> Implementers could use different ways to store and manage meta-data that
>> has to be accessed by the GFS Server.

>>  - Summary of existing or ongoing software
>> Yes. Can we add this as a one page document in the appendix? Since it is
>> difficult for one person to survey all the efforts and write about them,
>> can we have this done by individual contributors. Any implementer
>> (institution or vendor) who has some similar effort could make a one
>> page document about their overall architecture which could be added to
>> this workbook. Will one page in appendix be fine to describe the whole
>> system (from an architecture perspective)?

>>  - Last Telcon
>> The last week's telecon was mostly about the importance of non-WS client
>> protocol. A generic overview of status of the GFS was discussed. As we
>> are discussing it again here, you did not miss much

>> Cheers,
>> Arun

>> -----Original Message-----
>> From: owner-gfs-wg at ggf.org [mailto:owner-gfs-wg at ggf.org]On Behalf Of
>> Osamu Tatebe
>> Sent: Thursday, May 12, 2005 9:10 PM
>> To: gfs-wg at ggf.org
>> Subject: Re: [gfs-wg] RE: Grid File System Architecture Telecon
>> 
>> 
>> Hi All,
>> 
>> Unfortunately I also could not attend to the teleconference, but here
>> is my comment to the document.
>> 
>> * 1.1 Background
>> 
>> The first second paragraphs said the importance of logical resource
>> namespace, on the other hand, there is no explicit description
>> regarding relationship with Grid File System Services and the
>> namespace.
>> 
>> Also, in this document, several terms are used for namespace; logical
>> namespace, logical resource namespace, federated logical resource
>> namespace, ....  We need to define this term by referring to the RNS
>> document, and use consistently.
>> 
>> * Section 4.5 Standard Interfaces
>> 
>> I believe it is better to remove this section because this produces
>> huge confusion and misleads people.  At first, the interface to be
>> standardized is a service interface not a client interface.  This
>> point needs to be clarified.  Moreover, I cannot find the description
>> about GFS Server depicted in Figure 4.  What functionality is assumed?
>> This is much important to be described in this document, I believe.
>> 
>> For further discussion of GFS architecture, I suggest to summarize
>> architecture of existing and ongoing software.
>> 
>> Thanks,
>> Osamu
>> 
>> >> On Thu, 12 May 2005 09:08:43 -0700, Manuel Pereira
>> <mpereira at us.ibm.com> said:
>> 
>> >> Hello All,
>> >> We will initiate the telecon discussions on the GFS Architecture
>> >> Workbook (attached document) this Wednesday.
>> 
>> >> Unfortunately I was not able to make the call due to a
>> conflict in scheduling
>> >> with an OGSA-WG meeting (3:00-4:30PM PDT) I had to attend
>> to provide a monthly
>> >> report on the new OGSA-Naming WG and associated progress with RNS.
>> 
>> >> Will someone be sending out the minutes of the meeting?
>> 
>> >> Thank you,
>> >> Manuel Pereira
>> >> ===============================
>> >> IBM Almaden Research Center
>> >> ===============================
>> >> 650 Harry Road, San Jose, CA 95120
>> >> 1-408-927-1935 [T/L 457]
>> >> Pager: 800-946-4646 1492425
>> >> http://mvp3.almaden.ibm.com
>> >> mpereira at us.ibm.com
>> 