July22-2016Meeting.1

Agenda

1. Goals of filesystem

The filesystem should have the following characteristics.

• Robust
• High availability
• Highly secure
• Easily scalable
• Well-suited for academic and research uses
• Easily administered
• High performance
• Widely used
• Replication of selected data
• Single global namespace for all clients
• NFS / CIFS : Can not have global namespace across organizations comprised of heterogeneous platforms.
• Data readily distributed across an arbitrary mix of data centers
• Well-supported
• Well-suited for real-time collaboration across geographically-dispersed regions
• NFS / CIFS does not do this

2. Best way of achieving goals

3. Steps needed to achieve goals

4. Risks in achieving goals

5. Process needed to replace AFS

---

1. Need to go to AuriStorFS due to risk exposure. If there is a security or some other important problem with OAFS, at this point we cannot depend on OAFS to fix it right away, or at all.
2. Using NFS / CIFS means that an ACL set on Windows will not show up in Linux - i.e., cannot be seen on Linux - and vice versa. NFS / CIFS will show different ACLs depending on which OS the query comes from. This will cause great confusion. Unified ACLs across OSes is a requirement.
3. AFS sets ACLs according to its own scheme - not that of Posix, NFS, or CIFS. This results in ACL consistency across all platforms.
4. With NetApp, the design of the structured namespace must be done at the start of the implementation. That design is essentially locked in.
5. Unlike the NetApp filesystem, and other such hardware-software combinations, OAFS / AuriStorFS is not dependent on any particular hardware; whereas the NetApp filesystem requires NetApp hardware, OAFS / AuriStorFS works on virtually any storage device. Thus, use of OAFS / AuriStorFS avoids hardware vendor lock-in.
6. NetApp has had 10 consecutive quarters of of year-to-tear revenue decline, In 4FQ16 NetApp reduced headcount 11% from 3FQ16.
   NetAPP financials
7. Point 5 is sufficient to add to the list of filesystem requirements that the filesystem be agnostic with respect to storage vendors.
8. JA supplied OAFS volserver code change change to accept AuriStorFS volume dumps, even if AuriStorFS extensions are being used. AuriStorFS source code is not needed in any way. JA gave assurances that AuriStor would not leave a customer hanging.
9. NJIT can include in the contract agreement that AuriStor supply the necessary tool(s) to parse AuristorFS dumps so that they are readable by OAFS volserver.
10. The current method of managing software via volumes cannot be adequately replaced by tools available in NetApp.
11. No attempt was made to rate the degree to which AuriStorFS and NFS/CIFS meet the criteria in 1. above.
12. The cache coherency model used in AuriStorFS is superior to those used in NFS and CIFS. This was verified in the 8/9/16 discussion with Alan Tackett, Vanderbilt Univ. See : cache cohency. In that discussion, Dr. Tackett provided details of why VU, along with Univ. of Tennessee at Memphis and Knoxville, moved from NFS / CIFS to AuriStorFS, which included :
    • Permissions mangling (2. above)
    • NFS does not scale well
    • Far better data security