From carrier at cray.com Thu Mar 3 15:25:01 2011 From: carrier at cray.com (John Carrier) Date: Thu, 3 Mar 2011 09:25:01 -0600 Subject: [Twg] no TWG meeting today Message-ID: Dave and I have not had time this week to prepare for today's TWG meeting. We want to respect your time and have decided to cancel today's call. The working group still has to prioritize the requirements we have gathered. We are still looking for feedback. Our apologies. --jc From carrier at cray.com Thu Mar 10 09:07:36 2011 From: carrier at cray.com (John Carrier) Date: Thu, 10 Mar 2011 03:07:36 -0600 Subject: [Twg] meeting minutes for 2011-02-17, 2011-02-24, 2011-03-03 Message-ID: Attached are meeting minutes for the 2011-02-17 and 2011-02-04 meetings. There are no minutes for 2011-03-03 since that meeting was cancelled. Please let me know if you have any corrections to make and I'll repost. Our next meeting is Thursday, 3/10/2011 @ 9:30a PT/12:30p ET. (Dial-in numbers are 715-726-4994 or 866-304-8294, meeting ID and password are 7012090.) Our agenda is to prioritize the requirements. Dave posted the last update to the requirements on 2/12 to discuss at lists.opensfs.org. I haven't seen an update since then. I also haven't seen any further priority lists since we started discussing them at the 2/17 meeting. The TWG needs to submit the prioritized requirements list to the board. DaveD is slotted to present these at LUG. Please bring your top 5 items to this meeting (better yet, send them to the list before hand!). We need to move on the list in order to identify the requirements we want to use in the RFPs. My apologies for not getting the minutes distributed sooner. It's been a very hectic few weeks. Thanks, --jc -------------- next part -------------- OpenSFS Technical Working Group Meeting minutes : 02/24/2011 Concall: start : 9:30a PT, adjourn : 9:48a PT Attending Name Organization email ----------------- -------------- ---------------------------- Eric Monserrat Bull eric.monserrat at bull.net Diego Moreno Bull diego.moreno at bull.net Pascal Barbolosi Bull pascal.barbolosi at bull.net Cory Spitz Cray spitzcor at cray.com John Carrier Cray carrier at cray.com Justin Miller IU jupmille at indiana.edu Steve Simms IU ssimms at indiana.edu Shay Seager OpenSFS shay at opensfs.org Andreas Dilger Whamcloud adilger at whamcloud.com Eric Barton Whamcloud eeb at whamcloud.com Agenda priorities Meeting notes DaveD was off on vacation. No one had posted their requirements to the lists so there was nothing to reconcile during the meeting. We were, however, joined by three representatives from Bull. [My apologies if I misidentified any of these people or misspelled their names. Please send corrections. --jc] They noted that European OFS is gathering requirements from their membership. These are still several weeks out. Their focus will be performance, redundancy, recovery, backup/restore, management, and security. The priority will set the timeframe for the requirements. They defered discussing further until the European OFS publishes the results. Without priority lists, we adjourned the meeting early. -------------- next part -------------- OpenSFS Technical Working Group Meeting minutes : 02/17/2011 Concall: start : 9:30a PT Attending Name Organization email ----------------- -------------- ---------------------------- Cory Spitz Cray spitzcor at cray.com John Carrier Cray carrier at cray.com Steve Simms IU ssimms at indiana.edu Chris Morrone LLNL morrone2 at llnl.gov Shay Seager OpenSFS shay at opensfs.org Dave Dillow ORNL dillowda at ornl.gov Sarp Oral ORNL oralhs at ornl.gov Andreas Dilger Whamcloud adilger at whamcloud.com Eric Barton Whamcloud eeb at whamcloud.com Agenda requirements priorities Requirements Dave posted requirements update on Saturday 2/12. He needs more info on 2012/2014 projections for: single client creates/sec single client stats/sec directory listings/sec Eric asked about implied requirements that have not been explicitly stated, such as, interoperability and compatability between lustre versions. Maintaining interop between generations of Lustre costs money for development and testing. We understand that major version changes will make interoperability difficult, but expect that 2nd digit changes will not be as radical and should be interoperable with previous versions. We discussed doing rolling upgrades to transition to Lustre 2.0. The proposed scenario is to unmount the servers, upgrade the servers, reboot the servers, then mount the clients. This means there will be a service disruption to upgrade. Regardless of the upgrade path, the expectation is that there will be forward and backward compatibility of one revision. >> ACTION: Eric to provide text for interoperability and compatibility. Priorities Sequoia is a priority for LLNL. They will be deploying Lustre on ZFS and the OSD work started at Sun needs to be completed. Chris proposed the following for LLNL: - complete OSD - scalable fault management - LNET channel bonding to provide more than one pipe from one box. >> ACTION: John to provide text for channel bonding requirements - balancing storage usage and stripe allocation >> ACTION: Chris to provide text for rebalancing OSTs Steve Simms proposed the following priorites for IndianaU: - improved back-end - better fault management - metadata performance for WAN users IU wants a new back-end to replace ldiskfs that offers a low time for offline integrity checking and low impact for online integrity checking. Lustre RAID might be good with replicated metadata and triple RAID. We then discussed whether RAID6 was dead and looked at integrity checking options. There are three items being discussed to improve data integrity: end-to-end data integrity, online checking, and triple parity. The requirement is that we want zero interruption in the face of failures. Lustre-level replication needs to provide better availability than is possibe from the backend hardware. Lustre must handle failures of the backend storage and should replicate on other HW to improve availability. This requirement could also fall under scalable fault management. We ended up with two new requirements from this discussion: - resiliency of backend storage - availability of Lustre in face failures Fault management means faster failovers. Failover needs to be quicker and there should be better diags to show what is going on during fault recovery. Currently, failovers at IU take >20mins. IU liked size on MDS, which made the 2nd request much faster than the first. We discussed what making the MDS faster really meant and agreed that the requirement is to improve "ls -l" responsiveness and make "du" faster finding space in the directory. Next meeting (2/24) Everyone needs to put forward their top 3-5 requirments from the list. We don't need to rank all requirements, just prioritize our top ones. Send these priorities to the list and we'll organize the combined lists at the next meeting. From eeb at whamcloud.com Fri Mar 11 19:18:45 2011 From: eeb at whamcloud.com (Eric Barton) Date: Fri, 11 Mar 2011 19:18:45 -0000 Subject: [Twg] Protocol interoperation issues Message-ID: <011701cbe021$250f3f90$6f2dbeb0$@com> Lustre support for transparent rolling upgrade has been an assumption for some time now. However it comes at a cost. I'd like to explain how it is implemented so that we can all share a better understanding of this cost and let that guide OpenSFS development decisions. * LNET protocol version negotiation LNET has 2 levels of protocol - a generic LNET protocol is layered over an LND-specific protocol. LNDs exchange protocol version on the first communication between any pair of NIDs and use the earlier version. The generic LNET protocol version negotiation is implicit in the LND version negotiation. * LNET rolling upgrade Peer-to-peer communication state in LNET and its LNDs is discarded on any error and re-established on subsequent communication attempts. This allows LNET to be restarted or upgraded at any time, at the potential cost of a few dropped communications. Protocols layered over LNET (e.g. Lustre) must be coded to allow for this. LND protocol changes require at least 1 interim version of the LND to support both protocol versions. All LND instances must be upgraded to one of these interim versions before any can be upgraded to subsequent versions that remove support for the old protocol version. Changes to the LNET protocol affect all LNDs - i.e. all LNDs must be coded to support both old and new protocol versions. * Lustre protocol version negotiation Lustre peers negotiate protocol versions on connection establishment. Protocol features supported by either peer are represented using a bitmap so that only features supported by both peers are used. * Lustre Rolling Upgrade Lustre's recovery protocols make server restart/failover transparent to client applications. This can be exploited to allow rolling upgrades - where the server is upgraded before it is restarted. Much of recovery is implemented simply by replaying RPCs that hadn't yet been committed to disk by the previous instance of the server. This is a problem if there is a major server version change because the client's replay RPCs are now in an incompatible format. The solution to this is "Simplified Interoperation" which will provide an administrative server shutdown feature to force clients to minimize cached state. This reduces the set of RPCs required for recovery to a tiny fraction which are regenerated when the new server's protocol version is known and avoids the need to replay uncommitted RPCs entirely. 1.8/2.x upgrade The Lustre 1.8.5 client can talk the 2.x protocol, therefore servers may be upgraded to 2.x without requiring clients to upgrade immediately. Until simplified interoperation is implemented the upgrade process cannot be transparent to clients. They will be evicted and therefore applications running on them may see I/O errors during the server upgrade. The biggest protocol change on the horizon is to support IPv6. This cannot be put off indefinitely, so when it comes, should we try to support transparent rolling upgrade for it, or require a site-wide upgrade? * IPv6 Support for IPv6 requires a change in the NID format to accommodate a 128bit IPv6 address in the address-within-network field. This affects all protocol levels; LNDs, LNET and Lustre. Rolling upgrade will require versions of LNET (and all its LNDs) and Lustre that can communicate in both small and large NID LND/LNET/Lustre protocol versions. The version of Lustre will also have to be able to read and convert the small NID on-disk representation. Transparent rolling upgrade will require Simplified Interoperation support. However, at the cost of a 1-time site-wide upgrade most of this cost can be avoided. If IPv6 protocol version interoperation is not required, changing the protocols (LNET and Lustre) to use a large NID is relatively trivial since all that remains to be done after recompiling with the new NID format definition is to allow Lustre to read and convert any use of the binary small NID representation on disk. Cheers, Eric Eric Barton CTO Whamcloud, Inc. Tel: +44 (117) 330 1575 Mob: +44 (7920) 797 273 From ssseager at gmail.com Wed Mar 16 16:19:06 2011 From: ssseager at gmail.com (Shay Seager) Date: Wed, 16 Mar 2011 09:19:06 -0700 Subject: [Twg] OpenSFS Meeting LUG 2011 Message-ID: Hi OpenSFS Working Groups! The OpenSFS Board would like to invite you to attend a meeting we will be holding right after LUG on Thursday April 14th. Please see the attached PDF for more information. Feel free to e-mail, shay at opensfs.org, with any questions/comments. See you in Florida! Shay -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenSFS LUG 2011 Meeting.pdf Type: application/pdf Size: 40121 bytes Desc: not available URL: -------------- next part -------------- - - - Shay Seager Open SFS Secretary www.opensfs.org (925) 290-7641 shay at opensfs.org From carrier at cray.com Wed Mar 16 21:12:51 2011 From: carrier at cray.com (John Carrier) Date: Wed, 16 Mar 2011 16:12:51 -0500 Subject: [Twg] meeting minutes fro 2011-03-10 Message-ID: Attached are my summary notes from last week's meeting. Dave and I are still working on our recommendation for the board for review at our meeting tomorrow. Please send any corrections to the list. Thanks, --jc -------------- next part -------------- OpenSFS Technical Working Group Meeting minutes : 03/10/2011 Concall: start : 9:30a PT, adjourn : 11:20a PT Next meeting: Thursday, 3/17/2011 @ 9:30a PT/12:30p ET Dial-in numbers are 715-726-4994 or 866-304-8294. Meeting ID and password are 7012090. Attending : Name Organization email ----------------- -------------- ---------------------------- Cory Spitz Cray spitzcor at cray.com John Carrier Cray carrier at cray.com Steve Simms IU ssimms at indiana.edu Chris Morrone LLNL morrone2 at llnl.gov Shay Seager OpenSFS shay at opensfs.org Dave Dillow ORNL dillowda at ornl.gov Sarp Oral ORNL oralhs at ornl.gov Ercan Kamber RAID, Inc. ercan_kamber at raidinc.com Andreas Dilger Whamcloud adilger at whamcloud.com Eric Barton Whamcloud eeb at whamcloud.com Agenda : * resolve requirement priorities Requirements : We received the following ordered lists of the general requirements discussed during the last few meetings. (See 2/12 email from Dave Dillow to discuss at lists.opensfs.org for list of requirements.) ORNL - metadata scaling (ls -l, du, file opens for write) - failover and recovery - backend data system (expansion, larger luns, data protection) LLNL - complete OSD - scalable fault management - LNET channel bonding to provide more than one pipe from one box - balancing storage usage and stripe allocation for even object distribution Indiana - improved back-end - better fault management - metadata performance for WAN users Cray - single MDS performance - compatibility/interoperability [withdrawn during meeeting] - back-end improvements (>16TB LUNs, resiliency, rebuilds) - scalable fault management - HSM - scalable MDS performance - on-line file scrubber - end-to-end data integrity Discussion : Several expressed the hope that OpenSFS would take a broader view by considering work that needs to be done to pave the way for future functionality. Yes, there are feature/performance issues that have a clear target with immediate benefits, but foundational work will resolve some of the remaining technical debt in the Lustre code and set the stage for feature deliveries in 2013/2014. By the end of the meeting, we agreed to recommend to the board that OpenSFS pursue requirements for 1-2 performance features for 2012 delivery and 1-2 infrastructure projects that would lead to deliverables after 2012: Foundational projects : OSD restructuring to provide basis for alternate backends scalable fault management btrfs investigation Performance features : speed up MDS (ls -l, du) to use avail HW capabilities increase MDS capacity (distributed namespaces) Dave and John agreed to prepare a draft document describing these requirements for the next meeting. We also noted that OpenSFS needs to move quickly. There are several institutions waiting to invest in Lustre development in light of OpenSFS's decisions. The following is a summary by topic of the projects discussed during the call : Technical debt : What we describe as foundational features will address some of the technical debt remaining in the current Lustre 2.x code. We resolved that TWG requirements for any proposal should have vendors show how the deliverable not only did not add to technical debt, but paid off some of it too. It was suggested that the RFPs include boiler plate asking how new feature development would remove technical debt. Documentation and other release collateral should also be part of the RFP boiler plate. OSD : Much of our meeting time focused on the OSD restructuring needed to enable alternate file systems. This project will encounter significant technical debt. For example, the 2.0 stack includes 1.8 client side stack for the server to talk to OSTs. This is "Frankenstein" code that has been left behind and should not be carried forward. It is a technical debt that needs to be repaid (and fixed) during the OSD restructuring. OSD restructuring is a feature; the following are the requirements behind this feature : (1) The need for an interchangable backend. (2) Code reorganization to facilitate interop with different backend devices Funding partnerships : OSD is a major project. LLNL thinks it could easily consume all of OpenSFS's development budget. If OpenSFS is interested in OSD, then we need to consider how to partner with other companies and members on the RFPs. Another option is to ask the RFP responders to split a task into pieces that OpenSFS can fund. For example, 1/3 of the namespace ops use the OSD API. It could be a separate task to add the API to the other 2/3s (change logs, recover, OST, MGS, quotas). Btrfs : The requirements for an improved backend acknowledge that ldiskfs is a short-term solution. The OSD restructuring provides a mechanism for using other backend file systems, but it does not actually specify the ldiskfs replacement. For this, we would have to begin investigating alternatives, such as btrfs. The investigation should have detailed requirements to be sure that we understand stability, layering, and performance of the new file system. We need to complete the baseline investigation before starting on a btrfs OSD implementation. Lustre administrtion : Simple changes to improve administration (eg change protocol to include jobid) will require restructuring beyond the scope of the actual deliverable. This is another example a project that pays off technical debt. Error reporting (scalable fault management) : Foundational work is needed to make Lustre tractable to standard admin infrastructure. We cannot continue with error logs as being used today. Need instead to define how do errors in underlying HW get collected and made amenable to some other automated administration tools. There are two phases: - detection : collect and parse faults for notification - notification : scalable network to distribute errors for admin action The health network is the scalable infrastructure for distributing the notifications. The health network also used to detect nodes participating in the cluster. Distributed Namespace (aka CMD) : CMD is a solution to requirements for distributed namespaces or horizontal scalability of MDSs. The effort can be identified easily into achievable pieces. We can structure requirements to be aligned with two phases of development efforts. eg, - namespace distribution for phase 1 - distributed directories for phase 2 Note that failover with CMD is an additional discussion not covered by the phases above. Need non-blocking transactions for full server failure. Until then, have async replication of data and metadata. Don't confuse the issue. It was suggested that, in this context, distributed namespaces are not really foundational but performance related. The following projects were considered to be out of scope for OpenSFS TWG : HSM: There are technical issues being finalized in JC's group at CEA (immutable layouts, layout locking). Though its implementation is close to complete, it is believed that there is significant amount of work to get it tested for release. On larger systems, for example, expect HSM will run into performance problems related to change-log scalability issues. Therefore, expect considerable effort for productization of the proof of concept. Lustre documentation : There is currently no provision for Lustre documentation. The text is in the creative commons, but there is work to create an open source release. This effort, though, falls in the domain of the release planning working group. LUN size for ldiskfs : Belief is that this will get done. It is not core to OpenSFS's mission. Interoperability / Compatability : Rolling upgrades from Lustre 1.8 to Lustre 2.x will not be possible. It will require admin shutdown of the servers and client remount after the upgrade because of changes in the LNET protocol. From carrier at cray.com Thu Mar 17 16:22:17 2011 From: carrier at cray.com (John Carrier) Date: Thu, 17 Mar 2011 11:22:17 -0500 Subject: [Twg] DRAFT requirements document Message-ID: Attached is our proposed document for the board. Dave and I would like to discuss this with the team during today's call. Next meeting: Thursday, 3/17/2011 @ 9:30a PT/12:30p ET Dial-in numbers are 715-726-4994 or 866-304-8294. Meeting ID and password are 7012090. Sorry for sending at the last minute. --jc -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenSFS_TWG_2011-Requirements_DRAFT.pdf Type: application/pdf Size: 177429 bytes Desc: OpenSFS_TWG_2011-Requirements_DRAFT.pdf URL: From carrier at cray.com Thu Mar 17 19:21:16 2011 From: carrier at cray.com (John Carrier) Date: Thu, 17 Mar 2011 14:21:16 -0500 Subject: [Twg] meeting minutes for 2011-03-17 Message-ID: In record time, here are the minutes from today's TWG meeting. We reviewed the draft requirements document I sent to the reflector earlier this morning. The document includes our recommendations to the OpenSFS board. Dave and I ask all TWG members to read the document and provide us with your edits, comments, etc by the close of business this Monday, 3/21. We will submit the final document to the board on Tuesday. We want to be certain that we have captured all of the requirements that we discussed over the last couple months and have correctly presented the TWG's priorities. If you have different opinions on the requirements or our priorities, then please initiate a discussion of the topic on the TWG reflector. Thanks for your help. --jc -------------- next part -------------- OpenSFS Technical Working Group Meeting minutes : 03/17/2011 Concall: start : 9:30a PT, adjourn : 10:43a PT Next meeting: Thursday, 3/24/2011 @ 9:30a PDT/12:30p EDT (Note that the US is on daylight savings time) Dial-in numbers are 715-726-4994 or 866-304-8294. Meeting ID and password are 7012090. Attending : Name Organization email ----------------- -------------- ------------------------------- Diego Moreno Bull Diego.Moreno-Lazaro at bull.net Cory Spitz Cray spitzcor at cray.com John Carrier Cray carrier at cray.com Chris Morrone LLNL morrone2 at llnl.gov Shay Seager OpenSFS shay at opensfs.org Dave Dillow ORNL dillowda at ornl.gov Galen Shipman ORNL gshipman at ornl.gov Sarp Oral ORNL oralhs at ornl.gov Andreas Dilger Whamcloud adilger at whamcloud.com Nathan Rutman Xyratex nathan_rutman at xyratex.com Agenda : Review the summary document (OpenSFS_TWG_2011-Requirements_DRAFT.pdf) that John sent to the reflector before the meeting started Discussion : John and Dave created the doc from Dave's original notes (see 2/12 email) and the minutes of our previous meetings. The document includes all of the requirements we have gathered and recommends the top priorities we discussed at our 3/10 meeting. TWG members are requested to review the document and provide feedback by the close of business Monday, 3/21. Note that at the end of the document is a section called "Incomplete Requirements," which contains list of topics without descriptions. Please review this list and, if an item is one of your requirements, please send text to Dave and John with a suggestion of its position in the main document. Any item left in this section will be removed in the final version sent to the OpenSFS board. Document review : - backend storage : Chris asked that we remove the statement concerning the commercial viability of ZFS as a backing store. LLNL does not believe that distributing ZFS as a binary object is incompatible with the GPL. They know of at least one vendor who is planning to support ZFS on a commercial product. - rates and scales : discuss rows with missing data. We should look at the latest 2.0 manual for current Lustre limits. max subdirectories - Fujitsu's slides requested 1 billion. There was much discussion in our 2/10 meeting on the topic. There really is no limit. Can constrain this by allowing 1 directory per core. 2012: 1 million 2014: 10 million object size limits - currently there is a hard-coded client restriction to 2 TBs per object. It is possible to have the server export its object size limit to the client. Propose to scale the object size as 1/2 the OST size: 2012 2014 object size 16 TB 64 TB OST size 32 TB 128 TB # OSTs vs # OSSs - At our 2/10 meeting, we discussed a 1:1 match between OSTs and OSSs. This is never the case in reality. Recommend changing the OSTs to be 2x the OSSs and to reduce the 2014 OSS number to something more probable: 2012 2014 # OSS 1 thousand 4 thousand # OST 2 thousand 8 thousand file size - missing a value for 2014. 4 PB is reasonable, but may be better to leave blank if a firm requirement isn't needed. metadata rates : stats/s, creates/s etc. Motivation is improved performance of ls -l and du workloads. If no hard requirements for stats, then no reason to include them. Reasonable first approximation would be to match the file create rate. single process metadata IOPs - these came from Cray's HPCS program. The rates represent requirements for a single client and really for 2012, not 2014. - single file - really is single shared file and requires removal of number of OSTs on shared file size. (aka wide striping) - varying page-sizes - currently Lustre requires client page size to be no larger that server page size. There are some architectures where this could be violated. This is not a foundational feature and will be moved to another section. - remove dynamic OST addition/deletion appears to be a duplicate of "balancing storage use." Suggest it be combined with the previous requirement. Also can move adaptive stripe and mutable layouts from the incomplete section to this configuration. - LNET channel bonding - needs to be moved to peformance section - Other comments : Need to expand the executive summary at the top of the document to explain why the TWG decided to focus on performance rather than general administration for its near term priority. adjourn 10:43 PT From adilger at whamcloud.com Fri Mar 18 19:26:05 2011 From: adilger at whamcloud.com (Andreas Dilger) Date: Fri, 18 Mar 2011 13:26:05 -0600 Subject: [Twg] meeting minutes for 2011-03-17 In-Reply-To: References: Message-ID: <7D7500F3-86C4-4C10-928D-707FF2153BB6@whamcloud.com> On 2011-03-17, at 1:21 PM, John Carrier wrote: > In record time, here are the minutes from today's TWG meeting. We reviewed the draft requirements document I sent to the reflector earlier this morning. The document includes our recommendations to the OpenSFS board. > > Dave and I ask all TWG members to read the document and provide us with your edits, comments, etc by the close of business this Monday, 3/21. We will submit the final document to the board on Tuesday. We want to be certain that we have captured all of the requirements that we discussed over the last couple months and have correctly presented the TWG's priorities. John, for your reference, the published limits of Lustre 2.0 are at: http://wiki.lustre.org/manual/LustreManual20_HTML/SettingUpLustreSystem.html#50438256_84701 I don't think the limits are different between 1.8 and 2.0, just that the table in the 2.0 manual was updated more recently. It might make sense to structure the "filesystem limits" data in your submission to the board as a table with "current", "2012", and "2014" columns. > If you have different opinions on the requirements or our priorities, then please initiate a discussion of the topic on the TWG reflector. Cheers, Andreas -- Andreas Dilger Principal Engineer Whamcloud, Inc. From carrier at cray.com Fri Mar 18 19:53:32 2011 From: carrier at cray.com (John Carrier) Date: Fri, 18 Mar 2011 14:53:32 -0500 Subject: [Twg] meeting minutes for 2011-03-17 In-Reply-To: <7D7500F3-86C4-4C10-928D-707FF2153BB6@whamcloud.com> References: <7D7500F3-86C4-4C10-928D-707FF2153BB6@whamcloud.com> Message-ID: Thanks, Andreas. Your suggestion for modifying the table was exactly what I had in mind. --jc -----Original Message----- From: Andreas Dilger [mailto:adilger at whamcloud.com] Sent: Friday, March 18, 2011 12:26 PM To: John Carrier Cc: twg at lists.opensfs.org Subject: Re: [Twg] meeting minutes for 2011-03-17 On 2011-03-17, at 1:21 PM, John Carrier wrote: > In record time, here are the minutes from today's TWG meeting. We reviewed the draft requirements document I sent to the reflector earlier this morning. The document includes our recommendations to the OpenSFS board. > > Dave and I ask all TWG members to read the document and provide us with your edits, comments, etc by the close of business this Monday, 3/21. We will submit the final document to the board on Tuesday. We want to be certain that we have captured all of the requirements that we discussed over the last couple months and have correctly presented the TWG's priorities. John, for your reference, the published limits of Lustre 2.0 are at: http://wiki.lustre.org/manual/LustreManual20_HTML/SettingUpLustreSystem.html#50438256_84701 I don't think the limits are different between 1.8 and 2.0, just that the table in the 2.0 manual was updated more recently. It might make sense to structure the "filesystem limits" data in your submission to the board as a table with "current", "2012", and "2014" columns. > If you have different opinions on the requirements or our priorities, then please initiate a discussion of the topic on the TWG reflector. Cheers, Andreas -- Andreas Dilger Principal Engineer Whamcloud, Inc. From carrier at cray.com Mon Mar 21 06:03:08 2011 From: carrier at cray.com (John Carrier) Date: Mon, 21 Mar 2011 01:03:08 -0500 Subject: [Twg] TWG Requirements Draft #2 Message-ID: Dave and I have been using google docs to revise the requirements document that we reviewed at the last TWG meeting. With the link below, you should be able to view our new version and all updates: https://docs.google.com/document/d/1mLg4P-GEi_nP7g1APP4K8c1hgh_8mdqf0U2gWjh0aq0/edit?hl=en&authkey=COuayqYM There are still a number of "incomplete requirements" at the end of the document. We will remove this section and send the final doc to the board on Tuesday. Please complete your review and send us your comments by the close of business Monday. Thanks, --jc From carrier at cray.com Tue Mar 22 20:52:43 2011 From: carrier at cray.com (John Carrier) Date: Tue, 22 Mar 2011 15:52:43 -0500 Subject: [Twg] TWG Development Recommendations Message-ID: To the OpenSFS Board: The TWG has published its survey of Lustre requirements and project recommendations: https://docs.google.com/document/d/1mLg4P-GEi_nP7g1APP4K8c1hgh_8mdqf0U2gWjh0aq0/edit?hl=en&authkey=COuayqYM We request the OpenSFS board select two or more features, with at least one near-term and one foundational, for the TWG to pursue through RFPs. Dave Dillow John Carrier TWG co-chairs From dillowda at ornl.gov Thu Mar 24 10:57:14 2011 From: dillowda at ornl.gov (David Dillow) Date: Thu, 24 Mar 2011 06:57:14 -0400 Subject: [Twg] Meeting reminder Message-ID: <1300964234.1124.19.camel@obelisk.thedillows.org> This is a reminder of our meeting today, 3/24 at 9:30a PT / 12:30 ET to discuss our the next steps in defining our road map. Dial-in numbers are 715-726-4994 or 866-304-8294. The meeting ID and password are 7012090. Thanks, -- Dave Dillow National Center for Computational Science Oak Ridge National Laboratory (865) 241-6602 office From carrier at cray.com Wed Mar 30 16:18:17 2011 From: carrier at cray.com (John Carrier) Date: Wed, 30 Mar 2011 11:18:17 -0500 Subject: [Twg] TWG next steps Message-ID: The OpenSFS board met last Friday to review the Lustre requirements document that we had submitted earlier in the week (link below). They agreed with our recommendations to pursue RFPs to meet both our near-term performance and long-term foundational requirements. Galen Shipman will attend our call this Thursday to provide an overview of the board's decision. Dave and I then want to discuss with the team the next steps in the RFP process. As stated in our bylaws, our discussions about the RFPs themselves must exclude vendors who might respond to the RFPs. We will begin using the separate twg-rfp list for this purpose. If you represent a company that will not be bidding on the RFPs, then please sign-up at http://lists.opensfs.org/listinfo.cgi/twg-rfp-opensfs.org to help us with this work. Next meeting: 3/31 at 9:30a PT / 12:30 ET Dial-in numbers are 715-726-4994 or 866-304-8294. The meeting ID and password are 7012090. Requirements document https://docs.google.com/document/d/1mLg4P-GEi_nP7g1APP4K8c1hgh_8mdqf0U2gWjh0aq0/edit?hl=en&authkey=COuayqYM thanks, John & Dave TWG co-chairs -------------- next part -------------- An HTML attachment was scrubbed... URL: From carrier at cray.com Thu Mar 31 16:21:18 2011 From: carrier at cray.com (John Carrier) Date: Thu, 31 Mar 2011 11:21:18 -0500 Subject: [Twg] TWG next steps In-Reply-To: References: Message-ID: As background for our discussion of RFP process, I have added the whitepaper we wrote last year to google docs: https://docs.google.com/document/d/1vTRKUwSb2qEvkHKbK31hc5X_P0BvcfZOkeFHOrhTUkY/edit?hl=en&authkey=CODz_eYD From: discuss-bounces at lists.opensfs.org [mailto:discuss-bounces at lists.opensfs.org] On Behalf Of John Carrier Sent: Wednesday, March 30, 2011 9:18 AM To: discuss at lists.opensfs.org; twg at lists.opensfs.org Subject: [Discuss] TWG next steps The OpenSFS board met last Friday to review the Lustre requirements document that we had submitted earlier in the week (link below). They agreed with our recommendations to pursue RFPs to meet both our near-term performance and long-term foundational requirements. Galen Shipman will attend our call this Thursday to provide an overview of the board's decision. Dave and I then want to discuss with the team the next steps in the RFP process. As stated in our bylaws, our discussions about the RFPs themselves must exclude vendors who might respond to the RFPs. We will begin using the separate twg-rfp list for this purpose. If you represent a company that will not be bidding on the RFPs, then please sign-up at http://lists.opensfs.org/listinfo.cgi/twg-rfp-opensfs.org to help us with this work. Next meeting: 3/31 at 9:30a PT / 12:30 ET Dial-in numbers are 715-726-4994 or 866-304-8294. The meeting ID and password are 7012090. Requirements document https://docs.google.com/document/d/1mLg4P-GEi_nP7g1APP4K8c1hgh_8mdqf0U2gWjh0aq0/edit?hl=en&authkey=COuayqYM thanks, John & Dave TWG co-chairs -------------- next part -------------- An HTML attachment was scrubbed... URL: From carrier at cray.com Thu Mar 31 18:53:46 2011 From: carrier at cray.com (John Carrier) Date: Thu, 31 Mar 2011 13:53:46 -0500 Subject: [Twg] TWG RFP Message-ID: Just a reminder that the TWG is preparing RFP documents based on the recommendations we submitted to the OpenSFS board. If you are interested in contributing to the RFP documents, then please join the twg-rfp reflector. Thanks, --jc -------------- next part -------------- An HTML attachment was scrubbed... URL: