From peter.a.jones at intel.com Sat Jun 1 02:19:50 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Sat, 1 Jun 2013 02:19:50 +0000 Subject: [cdwg] Lustre 2.4.0 released Message-ID: We are pleased to announce that the Lustre 2.4.0 Release has been declared GA and is available for download . You can also grab the source from git The major release includes a number of new features including: DNE Phase 1 (LU-1187) Network Request Scheduler (LU-398) ZFS Support(LU-1305) see zfsonlinux.org for details on how to build this option Fuller details can be found in the change log, the scope statement and the test matrix The following are known issues in the Lustre 2.4 Release: LU-3430 : A rare race can result in an LBUG on an OSS while running the orr policy for NRS LU-3415: An LBUG hits the MDS when upgrading from 1.8.x to 2.4.0 with quotas enabled LU-3420: OI scrub not engaged after a file level backup running with DNE LU-3421: OSTs can erroneously report ENOSPC LU-3305: Metadata performance drop running with quotas Work is in progress for these issues. Please log any issues found in the issue tracking system We would like to thank OpenSFS for their contributions towards the cost of the release and also to all Lustre community members who have contributed to the release with code and/or testing. From uja at ornl.gov Mon Jun 3 17:41:20 2013 From: uja at ornl.gov (James A Simmons) Date: Mon, 03 Jun 2013 13:41:20 -0400 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <519D0361.5010805@llnl.gov> References: <519D0361.5010805@llnl.gov> Message-ID: <1370281280.6213.310.camel@bohr.ornl.gov> On Wed, 2013-05-22 at 13:41 -0400, Christopher J. Morrone wrote: > Hi folks, > > Please send us your list of planned development items for Lustre 2.5! > In two weeks at the next CDWG meeting we will be looking at the list of > proposed work and making our first, best attempt at pare it down to a > reasonable set of work for Lustre 2.5. > > If you have a new feature that you believe will be ready to land with in > the three month feature-landing window of Lustre 2.5, NOW is the time to > tell us! One I have act as the SuSE police to make sure ldiskfs is kept in sync. This covers all the ldiskfs work that will happen in 2.5. That will be done mostly by me. besides SLES11 other ldiskfs work -------------------------------------------------- LU-2479 - fix max_dir_size checking LU-2761 - sync ext4-kvalloc and journal callback LU-2762 to what is used mainline Lustre support against tip of Linus tree -------------------------------------------------- LU-1812 - 3.6/FC18 server patches LU-2686 - 3.7.2-201.fc18 client support LU-2800 - autoconf cleanup and code update for newer kernels. LU-2850 - 3.8 kernel support LU-2987 - llite destroy_inode should call rcu free LU-3097 - 3.9 kernel support Patchless Lustre -------------------------------------------------------------- LU-20 - Remove server side patches. Send block tunable patches upstream. Sub task below: LU-2498 - set IO scheduler to "deadline" LU-3406 - merge raid5-mmp-unplug patch upstream LU-2442 - quota scaling improvements. Need to be pushed LU-3305 upstream LU-684 - dev_rdonly patch is replaced by linux fail frame work. LU-2757 - move dynlocks to osd-ldiskfs and for the project I like to work on related to ldiskfs is to make ldiskfs patchless against the tip of Linus tree. Anything that will not be pushed upstream will be moved into osd-ldiskfs. No JIRA ticket for this work yet. Misc Lustre improvements ------------------------------------------------------------ LU-549 - packaged xattr in single RPC reply LU-2924 - shrink ldlm_poold workload LU-2145 - unified request handler for MGS LU-2059 - MGC to use OSD API LU-2158 - lvfs and fsfilt removal LNET work --------------------------------------------------------------- LU-2456 - Dynamic LNET config support LU-2950 - LNET route config LU-2466 - LNET hash tables LU-2934 - Router Priority Enable LNET to process its own checksums and do hand shaking with the ptlrpc layer. No JIRA ticket for this yet. ********************************************************** LNET change I would like so see these in 2.4.1 if possible as well :-) ********************************************************** LU-2212 - add crc32c module loading to libcfs LU-2544 - SMP scaling to Gemini driver ---------------------------------------------- Wish list work for myself that I most likely will not have ready for 2.5.X Enable compression of LNET traffic. Fix up Lustre so it can be built with llvm. First step to compile some of the more cpu intensive code in lustre as TSGI code to be executed by the GPU. From uja at ornl.gov Mon Jun 3 17:41:29 2013 From: uja at ornl.gov (James A Simmons) Date: Mon, 03 Jun 2013 13:41:29 -0400 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <519D0361.5010805@llnl.gov> References: <519D0361.5010805@llnl.gov> Message-ID: <1370281289.6213.312.camel@bohr.ornl.gov> On Wed, 2013-05-22 at 13:41 -0400, Christopher J. Morrone wrote: > Hi folks, > > Please send us your list of planned development items for Lustre 2.5! > In two weeks at the next CDWG meeting we will be looking at the list of > proposed work and making our first, best attempt at pare it down to a > reasonable set of work for Lustre 2.5. > > If you have a new feature that you believe will be ready to land with in > the three month feature-landing window of Lustre 2.5, NOW is the time to > tell us! One I have act as the SuSE police to make sure ldiskfs is kept in sync. This covers all the ldiskfs work that will happen in 2.5. That will be done mostly by me. besides SLES11 other ldiskfs work -------------------------------------------------- LU-2479 - fix max_dir_size checking LU-2761 - sync ext4-kvalloc and journal callback LU-2762 to what is used mainline Lustre support against tip of Linus tree -------------------------------------------------- LU-1812 - 3.6/FC18 server patches LU-2686 - 3.7.2-201.fc18 client support LU-2800 - autoconf cleanup and code update for newer kernels. LU-2850 - 3.8 kernel support LU-2987 - llite destroy_inode should call rcu free LU-3097 - 3.9 kernel support Patchless Lustre -------------------------------------------------------------- LU-20 - Remove server side patches. Send block tunable patches upstream. Sub task below: LU-2498 - set IO scheduler to "deadline" LU-3406 - merge raid5-mmp-unplug patch upstream LU-2442 - quota scaling improvements. Need to be pushed LU-3305 upstream LU-684 - dev_rdonly patch is replaced by linux fail frame work. LU-2757 - move dynlocks to osd-ldiskfs and for the project I like to work on related to ldiskfs is to make ldiskfs patchless against the tip of Linus tree. Anything that will not be pushed upstream will be moved into osd-ldiskfs. No JIRA ticket for this work yet. Misc Lustre improvements ------------------------------------------------------------ LU-549 - packaged xattr in single RPC reply LU-2924 - shrink ldlm_poold workload LU-2145 - unified request handler for MGS LU-2059 - MGC to use OSD API LU-2158 - lvfs and fsfilt removal LNET work --------------------------------------------------------------- LU-2456 - Dynamic LNET config support LU-2950 - LNET route config LU-2466 - LNET hash tables LU-2934 - Router Priority Enable LNET to process its own checksums and do hand shaking with the ptlrpc layer. No JIRA ticket for this yet. ********************************************************** LNET change I would like so see these in 2.4.1 if possible as well :-) ********************************************************** LU-2212 - add crc32c module loading to libcfs LU-2544 - SMP scaling to Gemini driver ---------------------------------------------- Wish list work for myself that I most likely will not have ready for 2.5.X Enable compression of the LNET packets. Fix up Lustre so it can be built with llvm. First step to compile some of the more cpu intensive code in lustre as TSGI code to be executed by the GPU. From andreas.dilger at intel.com Mon Jun 3 19:57:31 2013 From: andreas.dilger at intel.com (Dilger, Andreas) Date: Mon, 3 Jun 2013 19:57:31 +0000 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <1370281280.6213.310.camel@bohr.ornl.gov> Message-ID: On 2013/03/06 11:41 AM, "James A Simmons" wrote: >On Wed, 2013-05-22 at 13:41 -0400, Christopher J. Morrone wrote: >> Hi folks, >> >> Please send us your list of planned development items for Lustre 2.5! >> In two weeks at the next CDWG meeting we will be looking at the list of >> proposed work and making our first, best attempt at pare it down to a >> reasonable set of work for Lustre 2.5. >> >> If you have a new feature that you believe will be ready to land with >>in >> the three month feature-landing window of Lustre 2.5, NOW is the time >>to >> tell us! > >One I have act as the SuSE police to make sure ldiskfs is kept in sync. >This covers all the ldiskfs work that will happen in 2.5. That will be >done mostly by me. > >besides SLES11 other ldiskfs work >-------------------------------------------------- >LU-2479 - fix max_dir_size checking >LU-2761 - sync ext4-kvalloc and journal callback >LU-2762 to what is used mainline > >Lustre support against tip of Linus tree >-------------------------------------------------- >LU-1812 - 3.6/FC18 server patches >LU-2686 - 3.7.2-201.fc18 client support >LU-2800 - autoconf cleanup and code update for newer kernels. >LU-2850 - 3.8 kernel support >LU-2987 - llite destroy_inode should call rcu free >LU-3097 - 3.9 kernel support > >Patchless Lustre >-------------------------------------------------------------- >LU-20 - Remove server side patches. Send block tunable > patches upstream. Sub task below: > >LU-2498 - set IO scheduler to "deadline" >LU-2757 - move dynlocks to osd-ldiskfs Most of these are fine, since they involve porting patches that already exist. >LU-3406 - merge raid5-mmp-unplug patch upstream >LU-2442 - quota scaling improvements. Need to be pushed >LU-3305 upstream These depend on the willingness of the upstream patch maintainers to accept. Definitely something to track, but no guarantee of completion in 2.5. > LU-684 - dev_rdonly patch is replaced by linux fail frame work. This one doesn't have any existing patches, so needs new development work. >and for the project I like to work on related to ldiskfs is to make >ldiskfs patchless against the tip of Linus tree. Anything that will >not be pushed upstream will be moved into osd-ldiskfs. No JIRA ticket >for this work yet. I'm definitely in support of this. One of the main patches that needs work to be accepted upstream is the large_xattr patch. Please see LU-908 for what needs to be done before this patch can land upstream. The other major filesystem feature that is not yet landed upstream is the dirdata feature, used for FID-in-dirent. This doesn't have a lot of appeal to non-Lustre users today, but there may be a way to get this included upstream as part of an "attributes in dirent" feature that Ted discussed at one time. I'm not sure if he is working on that, but I can ask him. >Misc Lustre improvements >------------------------------------------------------------ >LU-549 - packaged xattr in single RPC reply Xyratex is working on this feature, so Fan Yong's patches under LU-549 are not planning on landing for 2.5. Not sure if they have a separate tracker for their work, or if they will reuse L-549. >LU-2924 - shrink ldlm_poold workload >LU-2145 - unified request handler for MGS >LU-2059 - MGC to use OSD API >LU-2158 - lvfs and fsfilt removal > >LNET work >--------------------------------------------------------------- >LU-2456 - Dynamic LNET config support >LU-2950 - LNET route config >LU-2466 - LNET hash tables >LU-2934 - Router Priority > >Enable LNET to process its own checksums and do hand shaking with >the ptlrpc layer. No JIRA ticket for this yet. Could you please explain this more? What is the benefit of adding another layer of checksumming at the LNEt level vs. the existing Lustre-level checksums, except overhead? >********************************************************** >LNET change I would like so see these in 2.4.1 if possible as well :-) >********************************************************** >LU-2212 - add crc32c module loading to libcfs There is no objection to this patch landing, except that nobody reported that the patch for that bug actually said that the patch actually fixed the problem for them. >LU-2544 - SMP scaling to Gemini driver >---------------------------------------------- > >Wish list work for myself that I most likely will not have ready for >2.5.X > >Enable compression of LNET traffic. Is there an expectation that this will improve throughput under normal usage, or would this only be good for WAN data transfers? As it is, the clients are already using considerable CPU for data handling, so I could only see this helping if the client data compression went all the way to the disk (i.e. it is compressed at the Lustre client, saved to disk in compressed form, and then decompressed again at the Lustre client), not at the LNET level. >Fix up Lustre so it can be built with llvm. First step to compile some >of the more cpu intensive code in lustre as TSGI code to be executed by >the GPU. This is theoretically interesting, but I'm not sure if there is any piece of Lustre code which would actually benefit from GPU offloading. I think that is only useful for CPU-intensive code that is run in a tight loop. It would also suffer if the code is doing data access, since it would need to do all the data access over the PCI bus in addition to the existing two network<->CPU<->storage transfers. Given that Lustre does auto-negotiation of the best checksum algorithms between the client and OST to use the hardware CRC support of the CPU, do you have any candidates that might benefit from this? Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division From uja at ornl.gov Tue Jun 4 14:22:25 2013 From: uja at ornl.gov (James A Simmons) Date: Tue, 04 Jun 2013 10:22:25 -0400 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: References: Message-ID: <1370355745.6213.525.camel@bohr.ornl.gov> > >LU-3406 - merge raid5-mmp-unplug patch upstream > >LU-2442 - quota scaling improvements. Need to be pushed > >LU-3305 upstream > > These depend on the willingness of the upstream patch maintainers to > accept. Definitely something to track, but no guarantee of completion in 2.5. True it could be awhile before these patches get merged upstream. We have to be persistent otherwise it will get dropped. > > LU-684 - dev_rdonly patch is replaced by linux fail frame work. > > This one doesn't have any existing patches, so needs new development work. I started to play with some code locally. Its pretty easy but it does require you to build a kernel with CONFIG_FAIL_MAKE_REQUEST. I put some notes in the JIRA ticket about how to use it. With test shots for 2.4 I haven't got to really testing it yet. Now I will have some free time to play with this again. > >and for the project I like to work on related to ldiskfs is to make > >ldiskfs patch less against the tip of Linus tree. Anything that will > >not be pushed upstream will be moved into osd-ldiskfs. No JIRA ticket > >for this work yet. > > I'm definitely in support of this. One of the main patches that needs work > to be accepted upstream is the large_xattr patch. Please see LU-908 for > what needs to be done before this patch can land upstream. > > The other major file system feature that is not yet landed upstream is the > dirdata feature, used for FID-in-dirent. This doesn't have a lot of appeal > to non-Lustre users today, but there may be a way to get this included > upstream as part of an "attributes in dirent" feature that Ted discussed at > one time. I'm not sure if he is working on that, but I can ask him. Do you a mailing lists links to these attribute discussions? It would be nice to see the frame work so we can move to it. Patch less ldiskfs is also a big task so we might not finish by the 2.5 release. > >LNET work > >--------------------------------------------------------------- > >LU-2456 - Dynamic LNET config support > >LU-2950 - LNET route config > >LU-2466 - LNET hash tables > >LU-2934 - Router Priority > > > >Enable LNET to process its own checksums and do hand shaking with > >the ptlrpc layer. No JIRA ticket for this yet. > > Could you please explain this more? What is the benefit of adding another > layer of checksumming at the LNEt level vs. the existing Lustre-level > checksums, except overhead? Their are companies that are using LNET for more than Lustre. These other non Lustre software products have a need to guarantee the data over the fabric as well. Lustre itself only does check summing for bulk messages and ignores small messages which also can suffer corruption. I agree if we already have a check sum done by the Lustre layer then we have no need to redo it. That is what I'm referring to by hand shaking. If done already don't go again. > >********************************************************** > >LNET change I would like so see these in 2.4.1 if possible as well :-) > >********************************************************** > >LU-2212 - add crc32c module loading to libcfs > > There is no objection to this patch landing, except that nobody reported > that the patch for that bug actually said that the patch actually fixed > the problem for them. I don't know what happen to JNET2000 but this patch makes my life a little easier. Without this patch I have to manually modprobe the crc32c module before starting lustre on my Cray test bed compute nodes. It auto-magically happens with this patch. > >Wish list work for myself that I most likely will not have ready for > >2.5.X > > > >Enable compression of LNET traffic. > > Is there an expectation that this will improve throughput under normal > usage, or would this only be good for WAN data transfers? As it is, the > clients are already using considerable CPU for data handling, so I could > only see this helping if the client data compression went all the way to > the disk (i.e. it is compressed at the Lustre client, saved to disk in > compressed form, and then decompressed again at the Lustre client), not > at the LNET level. Exactly what I was thinking. Both ZFS and btrfs support transparent compression. Also we have the e2compr project so ldiskfs could also support compression in place. As you pointed out this would be plus for WAN data transfers. At the same time it is expensive and should be not be used unless needed or your client happens to have the compute power. In the case of clients with Intel Phi cards or GPUs we now have the native CPUs often idle. > >Fix up Lustre so it can be built with llvm. First step to compile some > >of the more cpu intensive code in lustre as TSGI code to be executed by > >the GPU. > > This is theoretically interesting, but I'm not sure if there is any piece > of Lustre code which would actually benefit from GPU offloading. I think > that is only useful for CPU-intensive code that is run in a tight loop. > It would also suffer if the code is doing data access, since it would need > to do all the data access over the PCI bus in addition to the existing two > network<->CPU<->storage transfers. Today we have the PCI bus access penalty but that will be going away over the next few years. For example AMD has huma in the works. http://www.theregister.co.uk/2013/05/01/amd_huma As for what code would I targeted. Well the compression code :-) > Given that Lustre does auto-negotiation of the best checksum algorithms > between the client and OST to use the hardware CRC support of the CPU, do > you have any candidates that might benefit from this? Besides compression I can see encryption handling also benefiting. It is true check summing also could benefit. The most common use case for GPU offloading that already has been done is software raid but I have no idea if LAID will ever become a reality anymore. From kwestneat at ddn.com Tue Jun 4 17:17:02 2013 From: kwestneat at ddn.com (Kit Westneat) Date: Tue, 4 Jun 2013 13:17:02 -0400 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <51A92B89.5020204@llnl.gov> References: <519D0361.5010805@llnl.gov> <51A92B89.5020204@llnl.gov> Message-ID: <51AE210E.4000406@ddn.com> Hi Chris, This is our first pass at the things we'd like to see in 2.5: * LU-946: open file list * LU-744: single client performance regressions * LU-3420: OI scrubbing on secondary MDTs * RHEL 7 support. I believe it is scheduled to be released before Lustre 2.5. It looks like it will be based on Fedora 18, which is already in the autotest system, so it should be hopefully fairly simple to add support. * Mellanox OFED 2.0 support Thanks, Kit On 05/31/2013 07:00 PM, Christopher J. Morrone wrote: > Ok, I guess I'll start things off. Here is my first pass at things I > would like to see done by 2.5: > > LU-793 - Reconnections should not be refused when there is a request in > progress from this client. > LU-2498 - set block device IO scheduler to "deadline" > LU-1199 - lustre build system overhaul > LU-2182 - New llapi_layout API implementation > LU-3338 - IOC_MDC_GETFILESTRIPE can abuse vmalloc() > LU-2158 - remove lvfs and fsfilt code > LU-2161 - Remove last traces of obdfilter > LU-2096 - name ofd device type "ofd" instead of "obdfilter" > LU-911 - OFD Supporting Proc Updates > LU-2613 - opening and closing file can generate 'unrelaimable slab' space > LU-2259 - e2fsprogs: rename liblustreapi.h with lustreapi.h > LU-2600 - lustre metadata performance is very slow on zfs > LU-2476 - poor OST file creation rate performance with zfs backend > LU-2139 - track unstable pages on client > LU-1784 - freeing cached clean pages is slow > LU-744 - Single client's performance degradation on 2.1 > LU-576 - Incorrect build dependencies listed for libcfsutil.a > LU-2800 - build: clean out old autoconf options > > Chris > > On 05/22/2013 10:41 AM, Christopher J. Morrone wrote: >> Hi folks, >> >> Please send us your list of planned development items for Lustre 2.5! In >> two weeks at the next CDWG meeting we will be looking at the list of >> proposed work and making our first, best attempt at pare it down to a >> reasonable set of work for Lustre 2.5. >> >> If you have a new feature that you believe will be ready to land with in >> the three month feature-landing window of Lustre 2.5, NOW is the time to >> tell us! >> >> If you have pet bugs that are stuck on the back burner and need to be >> made a development priority for Lustre 2.5, NOW is the time to tell us! >> >> Your input is crucial if we are to properly scope the amount of change >> that we will introduce for Lustre 2.5, and properly scoping the work is >> a requirement if we are to produce a solid, on-time software release. >> >> So don't delay! Send us your list of desired Lustre 2.5 development >> items to this mailing list as soon as possible. >> >> Then, join us in the next CDWG call on June 5th to help us choose the >> subset of work that we believe is achievable* for Lustre 2.5. >> >> Chris >> >> * Not that this list will only be our best attempt at scoping what is >> reasonable, and is by no means a guarantee that any particular item will >> appear in Lustre 2.5. >> . >> > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From morrone2 at llnl.gov Tue Jun 4 17:57:52 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Tue, 04 Jun 2013 10:57:52 -0700 Subject: [cdwg] OpenSFS CDWG Call Message-ID: <51AE2AA0.6020504@llnl.gov> Hi all, This is a reminder that we will have a Community Development Working Group (CDWG) call on Wednesday, June 5, at 9:00am PDT. Thanks very much to James, Andreas, and Kit for their 2.5 Development Planning comments. Time is running short to get your items in. If anything, we're already behind schedule now that 2.4.0 has been tagged. So act _now_, or hold your tongue until the 2.6 planning effort! Agenda: * 2.4.0 comments * 2.5 Scoping/Development Planning Call-in: 866-914-3976 (925-424-8105) Passcode: 534986# Regards, Chris From frederik.ferner at diamond.ac.uk Tue Jun 4 18:03:33 2013 From: frederik.ferner at diamond.ac.uk (Frederik Ferner) Date: Tue, 4 Jun 2013 19:03:33 +0100 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <519D0361.5010805@llnl.gov> References: <519D0361.5010805@llnl.gov> Message-ID: <51AE2BF5.8060401@diamond.ac.uk> We'd like to see better performance for single client single process writes to single files, though I can see this might be more a longer term goal. I'm not sure there even is a ticket for this that I could reference, LU-744 comes close but I'm not sure it fully covers it. In our case it is tomography detectors writing single large files from on machine that will later be processed on clusters and writing we are no where near to saturating either the disks or the network links. It seems copying the data from userspace to kernel space on the client might be the bottleneck. Cheers, Frederik -- Frederik Ferner Senior Computer Systems Administrator phone: +44 1235 77 8624 Diamond Light Source Ltd. mob: +44 7917 08 5110 (Apologies in advance for the lines below. Some bits are a legal requirement and I have no control over them.) -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom From morrone2 at llnl.gov Tue Jun 4 18:13:10 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Tue, 04 Jun 2013 11:13:10 -0700 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <51AE2BF5.8060401@diamond.ac.uk> References: <519D0361.5010805@llnl.gov> <51AE2BF5.8060401@diamond.ac.uk> Message-ID: <51AE2E36.2090702@llnl.gov> Frederik, Thanks for the input! I think that issue is distinct enough from the other client problems that it warrants a new ticket. Please open a new ticket and let us know what the ticket number is. Chris On 06/04/2013 11:03 AM, Frederik Ferner wrote: > We'd like to see better performance for single client single process > writes to single files, though I can see this might be more a longer > term goal. I'm not sure there even is a ticket for this that I could > reference, LU-744 comes close but I'm not sure it fully covers it. > > In our case it is tomography detectors writing single large files from > on machine that will later be processed on clusters and writing we are > no where near to saturating either the disks or the network links. It > seems copying the data from userspace to kernel space on the client > might be the bottleneck. > > Cheers, > Frederik > From morrone2 at llnl.gov Tue Jun 4 18:22:57 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Tue, 04 Jun 2013 11:22:57 -0700 Subject: [cdwg] Make Lustre 2.5 a maintenance release? In-Reply-To: <519D061D.5050407@llnl.gov> References: <519D061D.5050407@llnl.gov> Message-ID: <51AE3081.2040507@llnl.gov> Folks, Since there have been no responses, this will not be discussed in tomorrow's meeting. This is an important decision, and one that we need to make soon, and advertise well. If this is what your organization wants, please speak up. Chris On 05/22/2013 10:53 AM, Christopher J. Morrone wrote: > Lustre community: > > As we all know, HSM is a Lustre feature that is desired by many, but was > not fully completed in time for the Lustre 2.4 release. As a result, > many folks are wondering if Lustre 2.4 is really the best branch to > support for a long period of time (18 or more months). > > HSM is very likely to be completed for 2.5, and multiple vendors and > organizations are planning to move to that version, and desire long term > support for that branch. > > On the other hand, we have for some time been advertising quite widely > that Lustre 2.4 will begin the next significant maintenance branch, and > some organizations have built there plans around that guidance. > > I would like to officially propose the following action: > > 1) Announce that Lustre 2.4 will have maintenance releases as planned, > but the maintenance window has been shortened to just 6 months. In > other words, we will only expect to see maintenance releases on Lustre > 2.4 branch for roughly 6 months. > > 2) Announce that the Lustre 2.5 branch will be long term maintenance > branch. > > Are there any objections? Any adjustments that should be made to that > statement? > > Chris > . > From morrone2 at llnl.gov Tue Jun 4 18:25:47 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Tue, 04 Jun 2013 11:25:47 -0700 Subject: [cdwg] Plea for contract requirements for maintenance branch(es) In-Reply-To: <519D0C76.2010808@llnl.gov> References: <519D0C76.2010808@llnl.gov> Message-ID: <51AE312B.4020300@llnl.gov> Everyone, Given the lack of responses, this will not be discussed in the CDWG call tomorrow. I consider the SFS-MAINT-001 modifications on hold until I get clear, specific guidance (specific contract wording is highly desired) about what you folks want to see changed. Chris On 05/22/2013 11:20 AM, Christopher J. Morrone wrote: > Hi folks, > > Work on updating the Lustre Development Community Tree Maintenance > contract (SFS-MAINT-001) is slow going. One of sticking points for me > is the topic of maintenance branches. > > A couple of organizations are very interested in extending the contract > to cover maintenance branches. I need those of you with interest in > doing so to provide me with the contractual requirements that you would > like to see added. > > Without requirements, I have nothing to put into writing, and without > that we can't really begin negotiating with Intel over the changes. > > If this is an area that you feel strongly about, please help propose > concrete contract changes that you would like to see! > > Chris > . > From kwestneat at ddn.com Tue Jun 4 18:27:40 2013 From: kwestneat at ddn.com (Kit Westneat) Date: Tue, 4 Jun 2013 14:27:40 -0400 Subject: [cdwg] Make Lustre 2.5 a maintenance release? In-Reply-To: <51AE3081.2040507@llnl.gov> References: <519D061D.5050407@llnl.gov> <51AE3081.2040507@llnl.gov> Message-ID: <51AE319C.6030908@ddn.com> Hi Chris, We have no objections to your plan. We would like 2.5 to be the next maintenance release. Thanks, Kit On 06/04/2013 02:22 PM, Christopher J. Morrone wrote: > Folks, > > Since there have been no responses, this will not be discussed in > tomorrow's meeting. This is an important decision, and one that we need > to make soon, and advertise well. If this is what your organization > wants, please speak up. > > Chris > > On 05/22/2013 10:53 AM, Christopher J. Morrone wrote: >> Lustre community: >> >> As we all know, HSM is a Lustre feature that is desired by many, but was >> not fully completed in time for the Lustre 2.4 release. As a result, >> many folks are wondering if Lustre 2.4 is really the best branch to >> support for a long period of time (18 or more months). >> >> HSM is very likely to be completed for 2.5, and multiple vendors and >> organizations are planning to move to that version, and desire long term >> support for that branch. >> >> On the other hand, we have for some time been advertising quite widely >> that Lustre 2.4 will begin the next significant maintenance branch, and >> some organizations have built there plans around that guidance. >> >> I would like to officially propose the following action: >> >> 1) Announce that Lustre 2.4 will have maintenance releases as planned, >> but the maintenance window has been shortened to just 6 months. In >> other words, we will only expect to see maintenance releases on Lustre >> 2.4 branch for roughly 6 months. >> >> 2) Announce that the Lustre 2.5 branch will be long term maintenance >> branch. >> >> Are there any objections? Any adjustments that should be made to that >> statement? >> >> Chris >> . >> > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From nic_henke at xyratex.com Tue Jun 4 18:29:35 2013 From: nic_henke at xyratex.com (Nic Henke) Date: Tue, 4 Jun 2013 13:29:35 -0500 Subject: [cdwg] Make Lustre 2.5 a maintenance release? In-Reply-To: <51AE3081.2040507@llnl.gov> References: <519D061D.5050407@llnl.gov> <51AE3081.2040507@llnl.gov> Message-ID: Sorry for the delay - but Xyratex would endorse this approach. I think there is a discussion to have with Intel for how to handle 2.4 -> 2.5 transition process and what we'd like to see therein. For instance (and this is not a Xyratex requirement!), do we greatly descope 2.5 in order to get a release with HSM server out as soon as possible ? Cheers, Nic Nicholas Henke • Senior Filesystem Developer Xyratex office: +1 (651)842 8471 • mobile: +1 (651)895 5795 www.xyratex.com Connect with Xyratex On Jun 4, 2013, at 1:22 PM, "Christopher J. Morrone" wrote: > Folks, > > Since there have been no responses, this will not be discussed in tomorrow's meeting. This is an important decision, and one that we need to make soon, and advertise well. If this is what your organization wants, please speak up. > > Chris > > On 05/22/2013 10:53 AM, Christopher J. Morrone wrote: >> Lustre community: >> >> As we all know, HSM is a Lustre feature that is desired by many, but was >> not fully completed in time for the Lustre 2.4 release. As a result, >> many folks are wondering if Lustre 2.4 is really the best branch to >> support for a long period of time (18 or more months). >> >> HSM is very likely to be completed for 2.5, and multiple vendors and >> organizations are planning to move to that version, and desire long term >> support for that branch. >> >> On the other hand, we have for some time been advertising quite widely >> that Lustre 2.4 will begin the next significant maintenance branch, and >> some organizations have built there plans around that guidance. >> >> I would like to officially propose the following action: >> >> 1) Announce that Lustre 2.4 will have maintenance releases as planned, >> but the maintenance window has been shortened to just 6 months. In >> other words, we will only expect to see maintenance releases on Lustre >> 2.4 branch for roughly 6 months. >> >> 2) Announce that the Lustre 2.5 branch will be long term maintenance >> branch. >> >> Are there any objections? Any adjustments that should be made to that >> statement? >> >> Chris >> . >> > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrone2 at llnl.gov Tue Jun 4 18:51:21 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Tue, 04 Jun 2013 11:51:21 -0700 Subject: [cdwg] Make Lustre 2.5 a maintenance release? In-Reply-To: References: <519D061D.5050407@llnl.gov> <51AE3081.2040507@llnl.gov> Message-ID: <51AE3729.2060706@llnl.gov> Nic, See the other thread where we're scoping 2.5. I would love to see some Xyratex input there. :) All, LLNL would like to see 2.5 scoped much more carefully than past releases. To that end, you'll see that LLNL's proposed list of work for 2.5 mostly fits into these categories: - Technical debt (unfinished OSD work, build system, etc.) - Long standing, ignored bugs - Client performance issues I believe that we're already on the path to scoping 2.5 more conservatively than previous release, for instance DNE2 has been pushed back to 2.6 at the earliest. But I think we have so much cleanup, bug fixing, and performance work to do that we'll need a full 6 months when you factor in HSM and anything else we need to get done. In summary: I agree that we need to descope features for 2.5. I think "as soon as possible" should be 6 months, but _really_ 6 months, not 1-2 months late (depending on how you count) like 2.4. Hitting the target this time will require much better scoping than we've done in the past. With 2.4, there were pretty major code changes, including incompatible on-disk-format changes, very late in the development cycle. I would like to see us avoid that in 2.5. I would further propose that we adjust the 2.5 development cycle to be 4 months for "feature" landing (including major technical debt code changes), and 2 months for RC testing, where we are really only landing bug fixes. But features really, _really_ need to be fully landed at the end of the 4 month cycle. We can't repeat what happened with DNE1 and NRS. Allowing things like that to slip past the feature landing window deadline creates a domino effect of delays that result in a late release. Chris On 06/04/2013 11:29 AM, Nic Henke wrote: > Sorry for the delay - but Xyratex would endorse this approach. > > I think there is a discussion to have with Intel for how to handle 2.4 > -> 2.5 transition process and what we'd like to see therein. For > instance (and this is not a Xyratex requirement!), do we greatly descope > 2.5 in order to get a release with HSM server out as soon as possible ? > > Cheers, > Nic > *Nicholas Henke* • *Senior Filesystem Developer* > *Xyratex* > *office:**+1 (651)842 8471* • *mobile:**+1 (651)895 5795* > www.xyratex.com > Connect with Xyratex > > On Jun 4, 2013, at 1:22 PM, "Christopher J. Morrone" > wrote: > >> Folks, >> >> Since there have been no responses, this will not be discussed in >> tomorrow's meeting. This is an important decision, and one that we >> need to make soon, and advertise well. If this is what your >> organization wants, please speak up. >> >> Chris >> >> On 05/22/2013 10:53 AM, Christopher J. Morrone wrote: >>> Lustre community: >>> >>> As we all know, HSM is a Lustre feature that is desired by many, but was >>> not fully completed in time for the Lustre 2.4 release. As a result, >>> many folks are wondering if Lustre 2.4 is really the best branch to >>> support for a long period of time (18 or more months). >>> >>> HSM is very likely to be completed for 2.5, and multiple vendors and >>> organizations are planning to move to that version, and desire long term >>> support for that branch. >>> >>> On the other hand, we have for some time been advertising quite widely >>> that Lustre 2.4 will begin the next significant maintenance branch, and >>> some organizations have built there plans around that guidance. >>> >>> I would like to officially propose the following action: >>> >>> 1) Announce that Lustre 2.4 will have maintenance releases as planned, >>> but the maintenance window has been shortened to just 6 months. In >>> other words, we will only expect to see maintenance releases on Lustre >>> 2.4 branch for roughly 6 months. >>> >>> 2) Announce that the Lustre 2.5 branch will be long term maintenance >>> branch. >>> >>> Are there any objections? Any adjustments that should be made to that >>> statement? >>> >>> Chris >>> . >>> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > From andreas.dilger at intel.com Tue Jun 4 20:53:12 2013 From: andreas.dilger at intel.com (Dilger, Andreas) Date: Tue, 4 Jun 2013 20:53:12 +0000 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <1370355745.6213.525.camel@bohr.ornl.gov> Message-ID: On 2013/04/06 8:22 AM, "James A Simmons" wrote: >> >LU-3406 - merge raid5-mmp-unplug patch upstream >> >LU-2442 - quota scaling improvements. Need to be pushed >> >LU-3305 upstream >> >> These depend on the willingness of the upstream patch maintainers to >> accept. Definitely something to track, but no guarantee of completion >>in 2.5. > >True it could be awhile before these patches get merged upstream. We >have to be persistent otherwise it will get dropped. > >> > LU-684 - dev_rdonly patch is replaced by linux fail frame work. >> >> This one doesn't have any existing patches, so needs new development >>work. > >I started to play with some code locally. Its pretty easy but it does >require you to build a kernel with CONFIG_FAIL_MAKE_REQUEST. I put some >notes in the JIRA ticket about how to use it. With test shots for 2.4 I >haven't got to really testing it yet. Now I will have some free time to >play with this again. I expect it might also be possible to build the dm-fail module against an existing kernel? I don't think we'll have any control over which options the vendor kernels will be built with. >> >and for the project I like to work on related to ldiskfs is to make >> >ldiskfs patch less against the tip of Linus tree. Anything that will >> >not be pushed upstream will be moved into osd-ldiskfs. No JIRA ticket >> >for this work yet. >> >> I'm definitely in support of this. One of the main patches that needs >>work >> to be accepted upstream is the large_xattr patch. Please see LU-908 for >> what needs to be done before this patch can land upstream. >> >> The other major file system feature that is not yet landed upstream is >>the >> dirdata feature, used for FID-in-dirent. This doesn't have a lot of >>appeal >> to non-Lustre users today, but there may be a way to get this included >> upstream as part of an "attributes in dirent" feature that Ted >>discussed at >> one time. I'm not sure if he is working on that, but I can ask him. > >Do you a mailing lists links to these attribute discussions? It would be >nice to see the frame work so we can move to it. Patch less ldiskfs is >also a big task so we might not finish by the 2.5 release. There was only a short discussion about this on the list: http://lists.openwall.net/linux-ext4/2012/08/11/8 >> >LNET work >> >--------------------------------------------------------------- >> >LU-2456 - Dynamic LNET config support >> >LU-2950 - LNET route config >> >LU-2466 - LNET hash tables >> >LU-2934 - Router Priority >> > >> >Enable LNET to process its own checksums and do hand shaking with >> >the ptlrpc layer. No JIRA ticket for this yet. >> >> Could you please explain this more? What is the benefit of adding >>another >> layer of checksumming at the LNEt level vs. the existing Lustre-level >> checksums, except overhead? > >Their are companies that are using LNET for more than Lustre. These >other non Lustre software products have a need to guarantee the data >over the fabric as well. Lustre itself only does check summing for >bulk messages and ignores small messages which also can suffer >corruption. I agree if we already have a check sum done by the Lustre >layer then we have no need to redo it. That is what I'm referring >to by hand shaking. If done already don't go again. > >> >********************************************************** >> >LNET change I would like so see these in 2.4.1 if possible as well :-) >> >********************************************************** >> >LU-2212 - add crc32c module loading to libcfs >> >> There is no objection to this patch landing, except that nobody reported >> that the patch for that bug actually said that the patch actually fixed >> the problem for them. > >I don't know what happen to JNET2000 but this patch makes my life a >little easier. Without this patch I have to manually modprobe the crc32c >module before starting lustre on my Cray test bed compute nodes. It >auto-magically happens with this patch. Could you please post this information into the Jira ticket. If this patch fixes the problem for you, it should be landed for 2.4 and 2.1. >> >Wish list work for myself that I most likely will not have ready for >> >2.5.X >> > >> >Enable compression of LNET traffic. >> >> Is there an expectation that this will improve throughput under normal >> usage, or would this only be good for WAN data transfers? As it is, the >> clients are already using considerable CPU for data handling, so I could >> only see this helping if the client data compression went all the way to >> the disk (i.e. it is compressed at the Lustre client, saved to disk in >> compressed form, and then decompressed again at the Lustre client), not >> at the LNET level. > >Exactly what I was thinking. Both ZFS and btrfs support transparent >compression. Also we have the e2compr project so ldiskfs could also >support compression in place. I don't think e2compr ever made it anywhere, and I haven't heard about it in many years. In any case, there is an open question of whether the OSD filesystems can be told that they are getting already-compressed data. > As you pointed out this would be plus for >WAN data transfers. At the same time it is expensive and should be not >be used unless needed or your client happens to have the compute power. >In the case of clients with Intel Phi cards or GPUs we now have the >native CPUs often idle. > >> >Fix up Lustre so it can be built with llvm. First step to compile some >> >of the more cpu intensive code in lustre as TSGI code to be executed by >> >the GPU. >> >> This is theoretically interesting, but I'm not sure if there is any >>piece >> of Lustre code which would actually benefit from GPU offloading. I >>think >> that is only useful for CPU-intensive code that is run in a tight loop. >> It would also suffer if the code is doing data access, since it would >>need >> to do all the data access over the PCI bus in addition to the existing >>two >> network<->CPU<->storage transfers. > >Today we have the PCI bus access penalty but that will be going away >over the next few years. For example AMD has huma in the works. > >http://www.theregister.co.uk/2013/05/01/amd_huma > >As for what code would I targeted. Well the compression code :-) This puts this firmly into the "some day when it is ready" category, and not really "ready for 2.5"... I'm not against any of these projects, but if the development hasn't already started on some major feature it is probably already too late for 2.5. >> Given that Lustre does auto-negotiation of the best checksum algorithms >> between the client and OST to use the hardware CRC support of the CPU, >>do >> you have any candidates that might benefit from this? > >Besides compression I can see encryption handling also benefiting. It is >true check summing also could benefit. The most common use case for GPU >offloading that already has been done is software raid but I have no >idea if LAID will ever become a reality anymore. Lustre hashing is already done by using the kernel cryptoapi, and I don't think it makes sense to expose Lustre to the details of the implementation. If there is a fast GPU-based crypto or hashing code then it should be added as a cryptoapi module and every kernel component can benefit. Similarly, if clients require this functionality without a GPU, they need to do this in software and cryptoapi is expected to have the most efficient assembly versions of the various algorithms. Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division From andreas.dilger at intel.com Tue Jun 4 21:06:36 2013 From: andreas.dilger at intel.com (Dilger, Andreas) Date: Tue, 4 Jun 2013 21:06:36 +0000 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <51AE2E36.2090702@llnl.gov> Message-ID: On 2013/04/06 12:13 PM, "Christopher J. Morrone" wrote: >Thanks for the input! I think that issue is distinct enough from the >other client problems that it warrants a new ticket. Please open a new >ticket and let us know what the ticket number is. There is already https://jira.hpdd.intel.com/browse/LU-3178 "single stream write to striped file is slow with 2.X clients", so no need to open a new ticket. I think it is important to remind people that "requirements gathering" for new features and development is really something for TWG and future RFPs. I think this CDWG process should be focussed on getting features/patches that are in progress or already finished into the 2.5 release. Unless there is some change to the schedule, the 2.5 feature freeze is at the end of July (i.e. 8 weeks from now), so that doesn't leave a lot of room for feature development that isn't already well underway. That doesn't mean that no work should be done on these other issues, just that they are not likely to be included into the 2.5 release if they are just starting. Cheers, Andreas >On 06/04/2013 11:03 AM, Frederik Ferner wrote: >> We'd like to see better performance for single client single process >> writes to single files, though I can see this might be more a longer >> term goal. I'm not sure there even is a ticket for this that I could >> reference, LU-744 comes close but I'm not sure it fully covers it. >> >> In our case it is tomography detectors writing single large files from >> on machine that will later be processed on clusters and writing we are >> no where near to saturating either the disks or the network links. It >> seems copying the data from userspace to kernel space on the client >> might be the bottleneck. >> >> Cheers, >> Frederik >> > >_______________________________________________ >cdwg mailing list >cdwg at lists.opensfs.org >http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division From nic_henke at xyratex.com Tue Jun 4 21:18:53 2013 From: nic_henke at xyratex.com (Nic Henke) Date: Tue, 4 Jun 2013 16:18:53 -0500 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: References: Message-ID: <7B6C97D2-AED0-4536-8BE2-B20B95F44668@xyratex.com> On Jun 4, 2013, at 4:06 PM, "Dilger, Andreas" wrote: > > Unless there is some change to the schedule, the 2.5 feature freeze is at > the end of July (i.e. 8 weeks from now), so that doesn't leave a lot of > room for feature development that isn't already well underway. That > doesn't > mean that no work should be done on these other issues, just that they are > not likely to be included into the 2.5 release if they are just starting. Andreas - can you point me at the location for these dates ? I came up empty searching on my own. Cheers, Nic From andreas.dilger at intel.com Tue Jun 4 22:30:31 2013 From: andreas.dilger at intel.com (Dilger, Andreas) Date: Tue, 4 Jun 2013 22:30:31 +0000 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <7B6C97D2-AED0-4536-8BE2-B20B95F44668@xyratex.com> Message-ID: On 2013/04/06 3:18 PM, "Nic Henke" wrote: >On Jun 4, 2013, at 4:06 PM, "Dilger, Andreas" >wrote: >> >> Unless there is some change to the schedule, the 2.5 feature freeze is >>at >> the end of July (i.e. 8 weeks from now), so that doesn't leave a lot of >> room for feature development that isn't already well underway. That >> doesn't >> mean that no work should be done on these other issues, just that they >>are >> not likely to be included into the 2.5 release if they are just >>starting. > >Andreas - can you point me at the location for these dates ? I came up >empty searching on my own. http://wiki.lustre.org/index.php/Lustre_Release_Information reports that 2.0 is targeted for release in Q2 2010. :-) And the movie "Lustre" got a rating of 2.5/10 at IMDB. https://wiki.hpdd.intel.com/display/PUB/Lustre+2.4+Scope+Statement has the 2.4 release schedule, and states (as was agreed by CDWG last year): Introduction Lustre feature releases follow a release train model, with feature releases targeted every 6 months. For the 2.4 release, the code freeze date has been shifted from a Dec 31, 2012 date to a January 31st, 2013 date in a one-time date adjustment to shift away from freeze dates falling near the Holidays. Key Deliverables and Milestones Feature Freeze: 2013-01-31 Code Freeze: 2013-03-31 2.4 Release GA: 2013-04-30 The corresponding 2.5 scope page does not exist yet, since the features for 2.5 are not yet finalized, but the 6-month schedule has been pretty steady for the past 2-3 releases, and Peter and I put the release schedule into every one of our LUG/SC presentations. The planned dates for 2.5 are: Feature Freeze: 2013-07-31 Code Freeze: 2013-09-30 2.5 Release GA: 2013-10-31 which are 6 months after the corresponding 2.4 dates. I agree it makes sense to have a single page which spells this out more clearly. Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division From sebastien.buisson at bull.net Wed Jun 5 13:14:58 2013 From: sebastien.buisson at bull.net (Sebastien Buisson) Date: Wed, 5 Jun 2013 15:14:58 +0200 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <51A92B89.5020204@llnl.gov> References: <519D0361.5010805@llnl.gov> <51A92B89.5020204@llnl.gov> Message-ID: <51AF39D2.9030407@bull.net> Hi there, At first glance, here is the list of things we would like to see in Lustre 2.5: - HSM; - single client performance improvements; - single shared file performance improvements. Thanks, Sebastien. Le 01/06/2013 01:00, Christopher J. Morrone a écrit : > Ok, I guess I'll start things off. Here is my first pass at things I > would like to see done by 2.5: > > LU-793 - Reconnections should not be refused when there is a request in > progress from this client. > LU-2498 - set block device IO scheduler to "deadline" > LU-1199 - lustre build system overhaul > LU-2182 - New llapi_layout API implementation > LU-3338 - IOC_MDC_GETFILESTRIPE can abuse vmalloc() > LU-2158 - remove lvfs and fsfilt code > LU-2161 - Remove last traces of obdfilter > LU-2096 - name ofd device type "ofd" instead of "obdfilter" > LU-911 - OFD Supporting Proc Updates > LU-2613 - opening and closing file can generate 'unrelaimable slab' space > LU-2259 - e2fsprogs: rename liblustreapi.h with lustreapi.h > LU-2600 - lustre metadata performance is very slow on zfs > LU-2476 - poor OST file creation rate performance with zfs backend > LU-2139 - track unstable pages on client > LU-1784 - freeing cached clean pages is slow > LU-744 - Single client's performance degradation on 2.1 > LU-576 - Incorrect build dependencies listed for libcfsutil.a > LU-2800 - build: clean out old autoconf options > > Chris > > On 05/22/2013 10:41 AM, Christopher J. Morrone wrote: >> Hi folks, >> >> Please send us your list of planned development items for Lustre 2.5! In >> two weeks at the next CDWG meeting we will be looking at the list of >> proposed work and making our first, best attempt at pare it down to a >> reasonable set of work for Lustre 2.5. >> >> If you have a new feature that you believe will be ready to land with in >> the three month feature-landing window of Lustre 2.5, NOW is the time to >> tell us! >> >> If you have pet bugs that are stuck on the back burner and need to be >> made a development priority for Lustre 2.5, NOW is the time to tell us! >> >> Your input is crucial if we are to properly scope the amount of change >> that we will introduce for Lustre 2.5, and properly scoping the work is >> a requirement if we are to produce a solid, on-time software release. >> >> So don't delay! Send us your list of desired Lustre 2.5 development >> items to this mailing list as soon as possible. >> >> Then, join us in the next CDWG call on June 5th to help us choose the >> subset of work that we believe is achievable* for Lustre 2.5. >> >> Chris >> >> * Not that this list will only be our best attempt at scoping what is >> reasonable, and is by no means a guarantee that any particular item will >> appear in Lustre 2.5. >> . >> > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From hamilton5 at llnl.gov Wed Jun 5 15:40:36 2013 From: hamilton5 at llnl.gov (Hamilton, Pam) Date: Wed, 5 Jun 2013 15:40:36 +0000 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: References: <7B6C97D2-AED0-4536-8BE2-B20B95F44668@xyratex.com> Message-ID: In addition, this announcement was sent out back in March by Jodi Levi: > -----Original Message----- > From: hpdd-discuss-bounces at lists.01.org [mailto:hpdd-discuss- > bounces at lists.01.org] On Behalf Of Levi, Jodi > Sent: Thursday, March 28, 2013 3:09 PM > To: hpdd-discuss at lists.01.org; cdwg at lists.opensfs.org > Subject: [HPDD-discuss] 2.5 Feature List Request > > Hi all! > As the Lustre 2.4 release draws close to completion, we are turning our > thoughts to the content of the Lustre 2.5 release. > > Lustre 2.5 is targeted for release in October 2013; therefore, any features to > be included will need to be ready for landing to Master in July 2013 in order > to allow adequate time for stabilization ahead of the release. > We will be discussing the Support Marix for 2.5 in upcoming CDWG meetings. > > If anyone is working on features that could be candidates to include in this > release, please let me know so that we can consider them in our planning. > > Thank you! > > Jodi Levi > Program Manager > Intel High Performance Data Division > mobile: 303-241-1428 > email: jodi.levi at intel.com Regards, Pam > -----Original Message----- > From: cdwg-bounces at lists.opensfs.org [mailto:cdwg- > bounces at lists.opensfs.org] On Behalf Of Dilger, Andreas > Sent: Tuesday, June 04, 2013 3:31 PM > To: Nic Henke > Cc: cdwg at lists.opensfs.org > Subject: Re: [cdwg] Lustre 2.5 Development Planning > > On 2013/04/06 3:18 PM, "Nic Henke" wrote: > >On Jun 4, 2013, at 4:06 PM, "Dilger, Andreas" > > > >wrote: > >> > >> Unless there is some change to the schedule, the 2.5 feature freeze > >>is at the end of July (i.e. 8 weeks from now), so that doesn't leave > >>a lot of room for feature development that isn't already well > >>underway. That doesn't mean that no work should be done on these > >>other issues, just that they are not likely to be included into the > >>2.5 release if they are just starting. > > > >Andreas - can you point me at the location for these dates ? I came up > >empty searching on my own. > > http://wiki.lustre.org/index.php/Lustre_Release_Information reports that > 2.0 is targeted for release in Q2 2010. :-) And the movie "Lustre" got a rating > of 2.5/10 at IMDB. > > https://wiki.hpdd.intel.com/display/PUB/Lustre+2.4+Scope+Statement has > the > 2.4 release schedule, and states (as was agreed by CDWG last year): > > Introduction > > Lustre feature releases follow a release train model, with feature > releases targeted every 6 months. For the 2.4 release, the code freeze > date has been shifted from a Dec 31, 2012 date to a January 31st, 2013 > date in a one-time date adjustment to shift away from freeze dates > falling near the Holidays. > > > Key Deliverables and Milestones > > Feature Freeze: 2013-01-31 > Code Freeze: 2013-03-31 > 2.4 Release GA: 2013-04-30 > > > The corresponding 2.5 scope page does not exist yet, since the features for > 2.5 are not yet finalized, but the 6-month schedule has been pretty steady > for the past 2-3 releases, and Peter and I put the release schedule into every > one of our LUG/SC presentations. > > The planned dates for 2.5 are: > > Feature Freeze: 2013-07-31 > Code Freeze: 2013-09-30 > 2.5 Release GA: 2013-10-31 > > > which are 6 months after the corresponding 2.4 dates. I agree it makes sense > to have a single page which spells this out more clearly. > > Cheers, Andreas > -- > Andreas Dilger > > Lustre Software Architect > Intel High Performance Data Division > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From simmonsja at ornl.gov Wed Jun 5 18:06:43 2013 From: simmonsja at ornl.gov (Simmons, James A.) Date: Wed, 5 Jun 2013 14:06:43 -0400 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: References: <1370355745.6213.525.camel@bohr.ornl.gov>, Message-ID: <6005A018DA581B4A80C06850774590950E5D710F5E@EXCHMB.ornl.gov> >>> > LU-684 - dev_rdonly patch is replaced by linux fail frame work. >>> >>> This one doesn't have any existing patches, so needs new development >>>work. >> >>I started to play with some code locally. Its pretty easy but it does >>require you to build a kernel with CONFIG_FAIL_MAKE_REQUEST. I put some >>notes in the JIRA ticket about how to use it. With test shots for 2.4 I >>haven't got to really testing it yet. Now I will have some free time to >>play with this again. >I expect it might also be possible to build the dm-fail module against an >existing kernel? I don't think we'll have any control over which options >the vendor kernels will be built with. We could use the dm-flaky module but that puts the requirement of always using device mapper and you need some userland setup to create special targets on top of the default targets created and from there we use the special target to perform the fail over. Of course we have other requirements with the fault injection system as I posted in LU-684 ticket . Can you use device mapper with loop back devices for the most basic testing? Since fail make request works on the block layer I know it will work with loop devices. Looking at flaky.c this code is a lot like the fail make request code so its not a big challenge either way. The cost either way chose to go is not coding but proper setup of the test bed. The only control over vendor options is if we build the kernels our selves which we already do at this time. I see for the current RHEL6.4 kernel that DM_FLAKY by enabled by default but you need currently a debug kernel for fail make request. So the question is how much pain do we want to suffer in setup for testing? I think this discussion should be cross referenced to the jira ticket. >>Do you a mailing lists links to these attribute discussions? It would be >>nice to see the frame work so we can move to it. Patch less ldiskfs is >>also a big task so we might not finish by the 2.5 release. > >There was only a short discussion about this on the list: >http://lists.openwall.net/linux-ext4/2012/08/11/8 Thank you for the link. From my web search nothing has moved in that direction. Maybe I missed something. >>> >********************************************************** >>> >LNET change I would like so see these in 2.4.1 if possible as well :-) >>> >********************************************************** >>> >LU-2212 - add crc32c module loading to libcfs >>> >>> There is no objection to this patch landing, except that nobody reported >>> that the patch for that bug actually said that the patch actually fixed >>> the problem for them. >> >>I don't know what happen to JNET2000 but this patch makes my life a >>little easier. Without this patch I have to manually modprobe the crc32c >>module before starting lustre on my Cray test bed compute nodes. It >>auto-magically happens with this patch. > >Could you please post this information into the Jira ticket. If this patch >fixes the problem for you, it should be landed for 2.4 and 2.1. Sure can. >> >Wish list work for myself that I most likely will not have ready for >> >2.5.X >> > >> >Enable compression of LNET traffic. >> >> Is there an expectation that this will improve throughput under normal >> usage, or would this only be good for WAN data transfers? As it is, the >> clients are already using considerable CPU for data handling, so I could >> only see this helping if the client data compression went all the way to >> the disk (i.e. it is compressed at the Lustre client, saved to disk in >> compressed form, and then decompressed again at the Lustre client), not >> at the LNET level. > >Exactly what I was thinking. Both ZFS and btrfs support transparent >compression. Also we have the e2compr project so ldiskfs could also >support compression in place. >I don't think e2compr ever made it anywhere, and I haven't heard about it >in many years. In any case, there is an open question of whether the OSD >filesystems can be told that they are getting already-compressed data. This is a big project under the wish list heading, Again likely a 2.6+ thing. Perhaps e2compr is something to look at? >>> >Fix up Lustre so it can be built with llvm. First step to compile some >>> >of the more cpu intensive code in lustre as TSGI code to be executed by >>> >the GPU. >>> >>> This is theoretically interesting, but I'm not sure if there is any >>>piece >>> of Lustre code which would actually benefit from GPU offloading. I >>>think >>> that is only useful for CPU-intensive code that is run in a tight loop. >>> It would also suffer if the code is doing data access, since it would >>>need >>> to do all the data access over the PCI bus in addition to the existing >>>two >>> network<->CPU<->storage transfers. >> >>Today we have the PCI bus access penalty but that will be going away >>over the next few years. For example AMD has huma in the works. >> >>http://www.theregister.co.uk/2013/05/01/amd_huma >> >>As for what code would I targeted. Well the compression code :-) > >This puts this firmly into the "some day when it is ready" category, and >not really "ready for 2.5"... Agree If you look at the earlier emails I labeled it the wish list section. Mind you making lustre build again llvm would not be a huge barrier. One nice out come of support llvm is that it is the back end of clang and that puts us in a position to handle the case if gcc is ever replaced by clang. Plus several years from now it could be that GPU cores could be booting a linux OS. We just don't know but it never hurts to be ready. I will spending a lot of cycles on other things so most likely llvm work is a 2.6+ thing. >>Besides compression I can see encryption handling also benefiting. It is >>true check summing also could benefit. The most common use case for GPU >>offloading that already has been done is software raid but I have no >>idea if LAID will ever become a reality anymore. >Lustre hashing is already done by using the kernel cryptoapi, and I don't >think it makes sense to expose Lustre to the details of the implementation. >If there is a fast GPU-based crypto or hashing code then it should be added >as a cryptoapi module and every kernel component can benefit. Similarly, >if clients require this functionality without a GPU, they need to do this in >software and cryptoapi is expected to have the most efficient assembly >versions of the various algorithms. You have a very good point about pushing such work upstream than with the lustre source. From uja at ornl.gov Fri Jun 7 12:47:20 2013 From: uja at ornl.gov (James A Simmons) Date: Fri, 07 Jun 2013 08:47:20 -0400 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: References: Message-ID: <1370609240.6213.538.camel@bohr.ornl.gov> I totally forgot one thing that would be a great help to us at the lab. File size on the MDS (SOM). Last time I talked to Oleg about this he didn't think it would be a big job to do. From carrier at cray.com Fri Jun 7 14:53:58 2013 From: carrier at cray.com (John Carrier) Date: Fri, 7 Jun 2013 14:53:58 +0000 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <1370609240.6213.538.camel@bohr.ornl.gov> References: <1370609240.6213.538.camel@bohr.ornl.gov> Message-ID: Please send requests for future development projects to the TWG too. Thanks, --jc -----Original Message----- From: cdwg-bounces at lists.opensfs.org [mailto:cdwg-bounces at lists.opensfs.org] On Behalf Of James A Simmons Sent: Friday, June 07, 2013 5:47 AM To: Dilger, Andreas Cc: cdwg at lists.opensfs.org Subject: Re: [cdwg] Lustre 2.5 Development Planning I totally forgot one thing that would be a great help to us at the lab. File size on the MDS (SOM). Last time I talked to Oleg about this he didn't think it would be a big job to do. _______________________________________________ cdwg mailing list cdwg at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From carrier at cray.com Fri Jun 7 15:04:06 2013 From: carrier at cray.com (John Carrier) Date: Fri, 7 Jun 2013 15:04:06 +0000 Subject: [cdwg] Make Lustre 2.5 a maintenance release? In-Reply-To: <51AE3081.2040507@llnl.gov> References: <519D061D.5050407@llnl.gov> <51AE3081.2040507@llnl.gov> Message-ID: Chris, Cray supports making Lustre 2.5 a maintenance release if it has the complete HSM support from CEA. My personal concern is that if we are uncertain that HSM will be complete in 2.5, then we run the risk of another bait and switch. 2.4 is a significant enough shift in the Lustre code base that I think it is really important that we get people moving from the 2.1 to 2.4 branches and not delaying a 2.4 transition waiting for 2.5 or whatever release has the HSM code. Your suggestion of describing a shortened maintenance window between 2.4 and the HSM release makes sense. --jc -----Original Message----- From: cdwg-bounces at lists.opensfs.org [mailto:cdwg-bounces at lists.opensfs.org] On Behalf Of Christopher J. Morrone Sent: Tuesday, June 04, 2013 11:23 AM To: cdwg at lists.opensfs.org Subject: Re: [cdwg] Make Lustre 2.5 a maintenance release? Folks, Since there have been no responses, this will not be discussed in tomorrow's meeting. This is an important decision, and one that we need to make soon, and advertise well. If this is what your organization wants, please speak up. Chris On 05/22/2013 10:53 AM, Christopher J. Morrone wrote: > Lustre community: > > As we all know, HSM is a Lustre feature that is desired by many, but > was not fully completed in time for the Lustre 2.4 release. As a > result, many folks are wondering if Lustre 2.4 is really the best > branch to support for a long period of time (18 or more months). > > HSM is very likely to be completed for 2.5, and multiple vendors and > organizations are planning to move to that version, and desire long > term support for that branch. > > On the other hand, we have for some time been advertising quite widely > that Lustre 2.4 will begin the next significant maintenance branch, > and some organizations have built there plans around that guidance. > > I would like to officially propose the following action: > > 1) Announce that Lustre 2.4 will have maintenance releases as planned, > but the maintenance window has been shortened to just 6 months. In > other words, we will only expect to see maintenance releases on Lustre > 2.4 branch for roughly 6 months. > > 2) Announce that the Lustre 2.5 branch will be long term maintenance > branch. > > Are there any objections? Any adjustments that should be made to that > statement? > > Chris > . > _______________________________________________ cdwg mailing list cdwg at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From andreas.dilger at intel.com Sat Jun 8 09:07:51 2013 From: andreas.dilger at intel.com (Dilger, Andreas) Date: Sat, 8 Jun 2013 09:07:51 +0000 Subject: [cdwg] Lustre 2.5 Development Planning In-Reply-To: <1370609240.6213.538.camel@bohr.ornl.gov> References: , <1370609240.6213.538.camel@bohr.ornl.gov> Message-ID: <2206C8EB-F162-48EF-A3F6-793DFC0EE258@intel.com> On 2013-06-07, at 6:49, "James A Simmons" wrote: > I totally forgot one thing that would be a great help to us at the lab. > File size on the MDS (SOM). Last time I talked to Oleg about this he > didn't think it would be a big job to do. Hmm, I'm not sure what Oleg is thinking, but if SOM was easy to finish we would have done this years ago... Cheers, Andreas From kevin_canady at xyratex.com Tue Jun 11 16:34:45 2013 From: kevin_canady at xyratex.com (Kevin Canady) Date: Tue, 11 Jun 2013 09:34:45 -0700 Subject: [cdwg] Pending items to land on Lustre Tree Message-ID: Chris, Peter and anyone else appropriate. I'm looking for suggestions on how to review and proceed with items awaiting landing. Some of them are over 24months old. I have a list of 65 items which are pending landing. Hopefully these contributions will further enhance and improve the Lustre experience for everyone. I've requested, first, an internal review to make sure all contributions are valid, complete and have been properly submitted. Once that is done what is the best course for reviewing these items in order to bring them to a close (landed)? Should we post the list with ticket numbers to CDWG? Appreciate thoughts and suggestions. Kevin P. Kevin Canady Director, Business Development Lustre and HPC Services kevin_canady at xyratex.com O: 510-687-5475 C: 415.505.7701 (best) From peter.a.jones at intel.com Tue Jun 11 17:09:22 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Tue, 11 Jun 2013 17:09:22 +0000 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: Message-ID: Kevin I think that the CDWG is the right place to review this information. It would definitely be prudent to scrub the list before circulating it to ensure that it only includes fixes relevant to master and not older releases that are no longer relevant. It would also help if engineers could mark any changes that do not need to land as abandoned in gerrit so as to reduce the noise. Thanks Peter On 6/11/13 9:34 AM, "Kevin Canady" wrote: >Chris, Peter and anyone else appropriate. > >I'm looking for suggestions on how to review and proceed with items >awaiting landing. Some of them are over 24months old. I have a list of >65 items which are pending landing. Hopefully these contributions will >further enhance and improve the Lustre experience for everyone. I've >requested, first, an internal review to make sure all contributions are >valid, complete and have been properly submitted. > >Once that is done what is the best course for reviewing these items in >order to bring them to a close (landed)? > >Should we post the list with ticket numbers to CDWG? > >Appreciate thoughts and suggestions. >Kevin > > >P. Kevin Canady >Director, Business Development Lustre and HPC Services >kevin_canady at xyratex.com >O: 510-687-5475 >C: 415.505.7701 (best) > > > >_______________________________________________ >cdwg mailing list >cdwg at lists.opensfs.org >http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From kevin_canady at xyratex.com Tue Jun 11 17:14:09 2013 From: kevin_canady at xyratex.com (Kevin Canady) Date: Tue, 11 Jun 2013 10:14:09 -0700 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: References: Message-ID: <8F7A569A-CF60-4301-AC97-55534D272A62@xyratex.com> Thanks Peter, Will do. I'll keep you posted. I expect to work on this more concretely after we return from ISC. Kevin On Jun 11, 2013, at 10:09 AM, "Jones, Peter A" wrote: > Kevin > > I think that the CDWG is the right place to review this information. It > would definitely be prudent to scrub the list before circulating it to > ensure that it only includes fixes relevant to master and not older > releases that are no longer relevant. It would also help if engineers > could mark any changes that do not need to land as abandoned in gerrit so > as to reduce the noise. > > Thanks > > Peter > > On 6/11/13 9:34 AM, "Kevin Canady" wrote: > >> Chris, Peter and anyone else appropriate. >> >> I'm looking for suggestions on how to review and proceed with items >> awaiting landing. Some of them are over 24months old. I have a list of >> 65 items which are pending landing. Hopefully these contributions will >> further enhance and improve the Lustre experience for everyone. I've >> requested, first, an internal review to make sure all contributions are >> valid, complete and have been properly submitted. >> >> Once that is done what is the best course for reviewing these items in >> order to bring them to a close (landed)? >> >> Should we post the list with ticket numbers to CDWG? >> >> Appreciate thoughts and suggestions. >> Kevin >> >> >> P. Kevin Canady >> Director, Business Development Lustre and HPC Services >> kevin_canady at xyratex.com >> O: 510-687-5475 >> C: 415.505.7701 (best) >> >> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > From peter.a.jones at intel.com Tue Jun 11 17:20:29 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Tue, 11 Jun 2013 17:20:29 +0000 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: <8F7A569A-CF60-4301-AC97-55534D272A62@xyratex.com> Message-ID: Thanks Kevin. Another thing that it would be very helpful to know along with the list is which of the issues have been reproduced on a vanilla 2.4.0 release. On 6/11/13 10:14 AM, "Kevin Canady" wrote: >Thanks Peter, Will do. I'll keep you posted. I expect to work on this >more concretely after we return from ISC. > >Kevin > >On Jun 11, 2013, at 10:09 AM, "Jones, Peter A" >wrote: > >> Kevin >> >> I think that the CDWG is the right place to review this information. It >> would definitely be prudent to scrub the list before circulating it to >> ensure that it only includes fixes relevant to master and not older >> releases that are no longer relevant. It would also help if engineers >> could mark any changes that do not need to land as abandoned in gerrit >>so >> as to reduce the noise. >> >> Thanks >> >> Peter >> >> On 6/11/13 9:34 AM, "Kevin Canady" wrote: >> >>> Chris, Peter and anyone else appropriate. >>> >>> I'm looking for suggestions on how to review and proceed with items >>> awaiting landing. Some of them are over 24months old. I have a list >>>of >>> 65 items which are pending landing. Hopefully these contributions >>>will >>> further enhance and improve the Lustre experience for everyone. I've >>> requested, first, an internal review to make sure all contributions are >>> valid, complete and have been properly submitted. >>> >>> Once that is done what is the best course for reviewing these items in >>> order to bring them to a close (landed)? >>> >>> Should we post the list with ticket numbers to CDWG? >>> >>> Appreciate thoughts and suggestions. >>> Kevin >>> >>> >>> P. Kevin Canady >>> Director, Business Development Lustre and HPC Services >>> kevin_canady at xyratex.com >>> O: 510-687-5475 >>> C: 415.505.7701 (best) >>> >>> >>> >>> _______________________________________________ >>> cdwg mailing list >>> cdwg at lists.opensfs.org >>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> > >_______________________________________________ >cdwg mailing list >cdwg at lists.opensfs.org >http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From morrone2 at llnl.gov Tue Jun 11 17:56:55 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Tue, 11 Jun 2013 10:56:55 -0700 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: References: Message-ID: <51B764E7.1040608@llnl.gov> Kevin, One thing that we should probably clarify is that you do not necessarily have "65 items which are pending landing". You may have 65 items submitted to the patch review system, but that doesn't mean that they are pending landing yet. I would say that a patch is only in the "pending landing" state when it has gotten all required positive reviews, and had the gatekeeper reviewer assigned. Pushing our patches to the review system is easy; addressing all of the faults in our patches that are found by the reviewers is often difficult and/or time consuming. But this process of review is one of the best tools that we have to maintain and improve the code quality in lustre. I would suggest that the first step for your guys are: 1) Complete all work required by the patch reviewers. 2) Refresh all patches that no longer apply cleanly. 3) If steps 1 and 2 are complete, and the patch is not getting attention, have a conversation in the associated Jira ticket. 4) Finally, if having a conversation in Jira does not achieve satisfaction, bring the issue to the attention of the CDWG through the cdwg mailing list. I have spotted several patches from Xyratex that haven't met steps 1 or 2, let alone 3. On one recent patch, a Xyratex developer flat out refused to rebase an out of date patch, and insisted that Intel do it for them. That attitude needs to be addressed. It is the patch submitter's responsibility to get his patch into proper shape for landing, not the patch reviewer's responsibility. Yes, this process can be long and even tedious at times. I understand. I feel your pain. I have had simple patches that I have needed to rebase several times because of other patches that landed before mine, introducing a conflict for my patch. But that is just a natural result of many people working together in the same areas of code. We can't possibly shift all of that work work up the chain to the top reviewers or the gatekeeper. That would be a fundamentally unscalable approach to software development. They can't possibly handle the work load. That is why the patch submitter must take on the responsibility of seeing the patch through to 100% completion. So I could be wrong, but I suspect that a much smaller number of those 65 patches that you mentioned are really ready to be discussed by the broader CDWG. But once your internal review is complete, and you have completed the steps that I've listed, we are happy to discuss any patches that you feel are being ignored! Chris On 06/11/2013 09:34 AM, Kevin Canady wrote: > Chris, Peter and anyone else appropriate. > > I'm looking for suggestions on how to review and proceed with items awaiting landing. Some of them are over 24months old. I have a list of 65 items which are pending landing. Hopefully these contributions will further enhance and improve the Lustre experience for everyone. I've requested, first, an internal review to make sure all contributions are valid, complete and have been properly submitted. > > Once that is done what is the best course for reviewing these items in order to bring them to a close (landed)? > > Should we post the list with ticket numbers to CDWG? > > Appreciate thoughts and suggestions. > Kevin > > > P. Kevin Canady > Director, Business Development Lustre and HPC Services > kevin_canady at xyratex.com > O: 510-687-5475 > C: 415.505.7701 (best) > > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > From kevin_canady at xyratex.com Tue Jun 11 18:12:16 2013 From: kevin_canady at xyratex.com (Kevin Canady) Date: Tue, 11 Jun 2013 11:12:16 -0700 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: <51B764E7.1040608@llnl.gov> References: <51B764E7.1040608@llnl.gov> Message-ID: <42B90EBB-4A5C-4587-8180-27C58FBE0B4C@xyratex.com> Hi Chris, Thank you very much, great feedback. I agree with your sentiments that keeping the machine moving requires proper submissions. Thus, i have asked us to review internally prior to truly making this an issue for CDWG to discuss. My motivation is to keep this transparent to encourage others to also contribute. Xyratex has made many submissions which have landed and will continue to do so. I'm sure the actual count is going to change since it will remain fluid as new fixes and submissions are made ready and upstreamed. It's a constant effort. The point of the number is that it was large enough to warrant some attention. The action for the moment is ours to clarify and clean up and then confirm to move forward. As you rightly point out we should not put undue burden on gatekeeping or release to clean up work of others so it is important process is followed. The goal is, if done properly, quality submissions will land quickly and be the benefit of all. Thank you again for the feedback, I'm encouraged rather than feeling pain, just want to make sure we are going down the right path, in the right forum. Many thanks, look forward to picking this up in a few weeks after ISC. Cheers, Kevin P. Kevin Canady Director, Business Development Lustre and HPC Services kevin_canady at xyratex.com 415.505.7701 On Jun 11, 2013, at 10:56 AM, "Christopher J. Morrone" wrote: > Kevin, > > One thing that we should probably clarify is that you do not necessarily have "65 items which are pending landing". You may have 65 items submitted to the patch review system, but that doesn't mean that they are pending landing yet. I would say that a patch is only in the "pending landing" state when it has gotten all required positive reviews, and had the gatekeeper reviewer assigned. > > Pushing our patches to the review system is easy; addressing all of the faults in our patches that are found by the reviewers is often difficult and/or time consuming. But this process of review is one of the best tools that we have to maintain and improve the code quality in lustre. > > I would suggest that the first step for your guys are: > > 1) Complete all work required by the patch reviewers. > > 2) Refresh all patches that no longer apply cleanly. > > 3) If steps 1 and 2 are complete, and the patch is not getting attention, have a conversation in the associated Jira ticket. > > 4) Finally, if having a conversation in Jira does not achieve satisfaction, bring the issue to the attention of the CDWG through the cdwg mailing list. > > I have spotted several patches from Xyratex that haven't met steps 1 or 2, let alone 3. On one recent patch, a Xyratex developer flat out refused to rebase an out of date patch, and insisted that Intel do it for them. That attitude needs to be addressed. It is the patch submitter's responsibility to get his patch into proper shape for landing, not the patch reviewer's responsibility. > > Yes, this process can be long and even tedious at times. I understand. I feel your pain. I have had simple patches that I have needed to rebase several times because of other patches that landed before mine, introducing a conflict for my patch. But that is just a natural result of many people working together in the same areas of code. > > We can't possibly shift all of that work work up the chain to the top reviewers or the gatekeeper. That would be a fundamentally unscalable approach to software development. They can't possibly handle the work load. That is why the patch submitter must take on the responsibility of seeing the patch through to 100% completion. > > So I could be wrong, but I suspect that a much smaller number of those 65 patches that you mentioned are really ready to be discussed by the broader CDWG. > > But once your internal review is complete, and you have completed the steps that I've listed, we are happy to discuss any patches that you feel are being ignored! > > Chris > > On 06/11/2013 09:34 AM, Kevin Canady wrote: >> Chris, Peter and anyone else appropriate. >> >> I'm looking for suggestions on how to review and proceed with items awaiting landing. Some of them are over 24months old. I have a list of 65 items which are pending landing. Hopefully these contributions will further enhance and improve the Lustre experience for everyone. I've requested, first, an internal review to make sure all contributions are valid, complete and have been properly submitted. >> >> Once that is done what is the best course for reviewing these items in order to bring them to a close (landed)? >> >> Should we post the list with ticket numbers to CDWG? >> >> Appreciate thoughts and suggestions. >> Kevin >> >> >> P. Kevin Canady >> Director, Business Development Lustre and HPC Services >> kevin_canady at xyratex.com >> O: 510-687-5475 >> C: 415.505.7701 (best) >> >> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From morrone2 at llnl.gov Thu Jun 13 17:39:47 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Thu, 13 Jun 2013 10:39:47 -0700 Subject: [cdwg] test Message-ID: <51BA03E3.6080901@llnl.gov> From peter.a.jones at intel.com Thu Jun 13 18:41:44 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Thu, 13 Jun 2013 18:41:44 +0000 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: <42B90EBB-4A5C-4587-8180-27C58FBE0B4C@xyratex.com> Message-ID: Hi Kevin I appreciate that you will be busy with ISC looming and so likely won't get to the review of the patches for a while. I had a quieter morning so I did an audit of the Xyratex master patches. I found that there are three patches ready to land - LU3096, LU-2212 and LU-2479. Oleg has been getting caught up with landings to master now that 2.4 is GA and I have asked him to prioritize these three for consideration. In addition, there are six patches are waiting for reviews from Intel engineers. Three of these relate to new features(LU-2488, LU-2869, and LU-2854) and three are bugs (LU-3399, LU-3277, and LU-1715). All feature landings have been on hold during the feature freeze, but now those should start moving. Some of the bugs have been waiting a few weeks for reviews – sorry about that, but engineers such as Oleg and Andreas are very busy. We'll get some attention to these as soon as possible and the reason that they are so overloaded is that their feedback is worth the wait :-) There is one patch (LU-3155) just uploaded yesterday that is still running through regression testing One patch(LU-901) failed regression tests and the Intel engineer responsible has not yet advised whether the failure is related to the proposed patch or not – sorry about that! I have followed up with the engineer to ensure that this is made clear in the ticket what the next steps should be. Finally, I discovered that a patch for LU-1409 had slipped through the net because it had been uploaded into gerrit against a closed JIRA ticket with no associated comment being made in the JIRA ticket and no reviewers being added. It's not quite clear to me whether this is follow on work or really a new issue. I have posted a question on the JIRA ticket with a view to getting this cleared up and we will take action accordingly. As Chris suggested, there are also a number of other patches which are waiting for revisions or clarifications from Xyratex engineers. As part of your internal review it would be great to mark those which are not relevant to current master to be marked as deprecated so that we can focus on those patches that are important. Thanks Peter On 6/11/13 11:12 AM, "Kevin Canady" > wrote: Hi Chris, Thank you very much, great feedback. I agree with your sentiments that keeping the machine moving requires proper submissions. Thus, i have asked us to review internally prior to truly making this an issue for CDWG to discuss. My motivation is to keep this transparent to encourage others to also contribute. Xyratex has made many submissions which have landed and will continue to do so. I'm sure the actual count is going to change since it will remain fluid as new fixes and submissions are made ready and upstreamed. It's a constant effort. The point of the number is that it was large enough to warrant some attention. The action for the moment is ours to clarify and clean up and then confirm to move forward. As you rightly point out we should not put undue burden on gatekeeping or release to clean up work of others so it is important process is followed. The goal is, if done properly, quality submissions will land quickly and be the benefit of all. Thank you again for the feedback, I'm encouraged rather than feeling pain, just want to make sure we are going down the right path, in the right forum. Many thanks, look forward to picking this up in a few weeks after ISC. Cheers, Kevin P. Kevin Canady Director, Business Development Lustre and HPC Services kevin_canady at xyratex.com 415.505.7701 On Jun 11, 2013, at 10:56 AM, "Christopher J. Morrone" > wrote: Kevin, One thing that we should probably clarify is that you do not necessarily have "65 items which are pending landing". You may have 65 items submitted to the patch review system, but that doesn't mean that they are pending landing yet. I would say that a patch is only in the "pending landing" state when it has gotten all required positive reviews, and had the gatekeeper reviewer assigned. Pushing our patches to the review system is easy; addressing all of the faults in our patches that are found by the reviewers is often difficult and/or time consuming. But this process of review is one of the best tools that we have to maintain and improve the code quality in lustre. I would suggest that the first step for your guys are: 1) Complete all work required by the patch reviewers. 2) Refresh all patches that no longer apply cleanly. 3) If steps 1 and 2 are complete, and the patch is not getting attention, have a conversation in the associated Jira ticket. 4) Finally, if having a conversation in Jira does not achieve satisfaction, bring the issue to the attention of the CDWG through the cdwg mailing list. I have spotted several patches from Xyratex that haven't met steps 1 or 2, let alone 3. On one recent patch, a Xyratex developer flat out refused to rebase an out of date patch, and insisted that Intel do it for them. That attitude needs to be addressed. It is the patch submitter's responsibility to get his patch into proper shape for landing, not the patch reviewer's responsibility. Yes, this process can be long and even tedious at times. I understand. I feel your pain. I have had simple patches that I have needed to rebase several times because of other patches that landed before mine, introducing a conflict for my patch. But that is just a natural result of many people working together in the same areas of code. We can't possibly shift all of that work work up the chain to the top reviewers or the gatekeeper. That would be a fundamentally unscalable approach to software development. They can't possibly handle the work load. That is why the patch submitter must take on the responsibility of seeing the patch through to 100% completion. So I could be wrong, but I suspect that a much smaller number of those 65 patches that you mentioned are really ready to be discussed by the broader CDWG. But once your internal review is complete, and you have completed the steps that I've listed, we are happy to discuss any patches that you feel are being ignored! Chris On 06/11/2013 09:34 AM, Kevin Canady wrote: Chris, Peter and anyone else appropriate. I'm looking for suggestions on how to review and proceed with items awaiting landing. Some of them are over 24months old. I have a list of 65 items which are pending landing. Hopefully these contributions will further enhance and improve the Lustre experience for everyone. I've requested, first, an internal review to make sure all contributions are valid, complete and have been properly submitted. Once that is done what is the best course for reviewing these items in order to bring them to a close (landed)? Should we post the list with ticket numbers to CDWG? Appreciate thoughts and suggestions. Kevin P. Kevin Canady Director, Business Development Lustre and HPC Services kevin_canady at xyratex.com O: 510-687-5475 C: 415.505.7701 (best) _______________________________________________ cdwg mailing list cdwg at lists.opensfs.org http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From kevin_canady at xyratex.com Thu Jun 13 20:46:34 2013 From: kevin_canady at xyratex.com (Kevin Canady) Date: Thu, 13 Jun 2013 13:46:34 -0700 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: References: Message-ID: <5B53B0CD-E7BB-4F9A-A055-855B36448CF6@xyratex.com> This is great! I appreciate the commitment to process. Look forward to picking this up after next week. Kevin Sent from my iPhone On Jun 13, 2013, at 11:41 AM, "Jones, Peter A" wrote: > Hi Kevin > > I appreciate that you will be busy with ISC looming and so likely won't get to the review of the patches for a while. I had a quieter morning so I did an audit of the Xyratex master patches. > > I found that there are three patches ready to land - LU3096, LU-2212 and LU-2479. Oleg has been getting caught up with landings to master now that 2.4 is GA and I have asked him to prioritize these three for consideration. > > In addition, there are six patches are waiting for reviews from Intel engineers. Three of these relate to new features(LU-2488, LU-2869, and LU-2854) and three are bugs (LU-3399, LU-3277, and LU-1715). All feature landings have been on hold during the feature freeze, but now those should start moving. Some of the bugs have been waiting a few weeks for reviews – sorry about that, but engineers such as Oleg and Andreas are very busy. We'll get some attention to these as soon as possible and the reason that they are so overloaded is that their feedback is worth the wait :-) > > There is one patch (LU-3155) just uploaded yesterday that is still running through regression testing > > One patch(LU-901) failed regression tests and the Intel engineer responsible has not yet advised whether the failure is related to the proposed patch or not – sorry about that! I have followed up with the engineer to ensure that this is made clear in the ticket what the next steps should be. > > Finally, I discovered that a patch for LU-1409 had slipped through the net because it had been uploaded into gerrit against a closed JIRA ticket with no associated comment being made in the JIRA ticket and no reviewers being added. It's not quite clear to me whether this is follow on work or really a new issue. I have posted a question on the JIRA ticket with a view to getting this cleared up and we will take action accordingly. > > As Chris suggested, there are also a number of other patches which are waiting for revisions or clarifications from Xyratex engineers. As part of your internal review it would be great to mark those which are not relevant to current master to be marked as deprecated so that we can focus on those patches that are important. > > Thanks > > Peter > > > On 6/11/13 11:12 AM, "Kevin Canady" > wrote: > > Hi Chris, > Thank you very much, great feedback. I agree with your sentiments that keeping the machine moving requires proper submissions. Thus, i have asked us to review internally prior to truly making this an issue for CDWG to discuss. My motivation is to keep this transparent to encourage others to also contribute. Xyratex has made many submissions which have landed and will continue to do so. I'm sure the actual count is going to change since it will remain fluid as new fixes and submissions are made ready and upstreamed. It's a constant effort. The point of the number is that it was large enough to warrant some attention. The action for the moment is ours to clarify and clean up and then confirm to move forward. > > As you rightly point out we should not put undue burden on gatekeeping or release to clean up work of others so it is important process is followed. The goal is, if done properly, quality submissions will land quickly and be the benefit of all. > > Thank you again for the feedback, I'm encouraged rather than feeling pain, just want to make sure we are going down the right path, in the right forum. > > Many thanks, look forward to picking this up in a few weeks after ISC. > > Cheers, > Kevin > > > P. Kevin Canady > Director, Business Development Lustre and HPC Services > kevin_canady at xyratex.com > 415.505.7701 > > > > On Jun 11, 2013, at 10:56 AM, "Christopher J. Morrone" > wrote: > > Kevin, > > One thing that we should probably clarify is that you do not necessarily have "65 items which are pending landing". You may have 65 items submitted to the patch review system, but that doesn't mean that they are pending landing yet. I would say that a patch is only in the "pending landing" state when it has gotten all required positive reviews, and had the gatekeeper reviewer assigned. > > Pushing our patches to the review system is easy; addressing all of the faults in our patches that are found by the reviewers is often difficult and/or time consuming. But this process of review is one of the best tools that we have to maintain and improve the code quality in lustre. > > I would suggest that the first step for your guys are: > > 1) Complete all work required by the patch reviewers. > > 2) Refresh all patches that no longer apply cleanly. > > 3) If steps 1 and 2 are complete, and the patch is not getting attention, have a conversation in the associated Jira ticket. > > 4) Finally, if having a conversation in Jira does not achieve satisfaction, bring the issue to the attention of the CDWG through the cdwg mailing list. > > I have spotted several patches from Xyratex that haven't met steps 1 or 2, let alone 3. On one recent patch, a Xyratex developer flat out refused to rebase an out of date patch, and insisted that Intel do it for them. That attitude needs to be addressed. It is the patch submitter's responsibility to get his patch into proper shape for landing, not the patch reviewer's responsibility. > > Yes, this process can be long and even tedious at times. I understand. I feel your pain. I have had simple patches that I have needed to rebase several times because of other patches that landed before mine, introducing a conflict for my patch. But that is just a natural result of many people working together in the same areas of code. > > We can't possibly shift all of that work work up the chain to the top reviewers or the gatekeeper. That would be a fundamentally unscalable approach to software development. They can't possibly handle the work load. That is why the patch submitter must take on the responsibility of seeing the patch through to 100% completion. > > So I could be wrong, but I suspect that a much smaller number of those 65 patches that you mentioned are really ready to be discussed by the broader CDWG. > > But once your internal review is complete, and you have completed the steps that I've listed, we are happy to discuss any patches that you feel are being ignored! > > Chris > > On 06/11/2013 09:34 AM, Kevin Canady wrote: > Chris, Peter and anyone else appropriate. > > I'm looking for suggestions on how to review and proceed with items awaiting landing. Some of them are over 24months old. I have a list of 65 items which are pending landing. Hopefully these contributions will further enhance and improve the Lustre experience for everyone. I've requested, first, an internal review to make sure all contributions are valid, complete and have been properly submitted. > > Once that is done what is the best course for reviewing these items in order to bring them to a close (landed)? > > Should we post the list with ticket numbers to CDWG? > > Appreciate thoughts and suggestions. > Kevin > > > P. Kevin Canady > Director, Business Development Lustre and HPC Services > kevin_canady at xyratex.com > O: 510-687-5475 > C: 415.505.7701 (best) > > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > From morrone2 at llnl.gov Thu Jun 13 21:35:41 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Thu, 13 Jun 2013 14:35:41 -0700 Subject: [cdwg] Should we have CDWG call on June 19? Message-ID: <51BA3B2D.4040307@llnl.gov> Hi folks, A number of people will not be available for the June 19 CDWG call due to ISC'13. I am inclined to cancel the meeting, unless the remaining folks have things they would like to discuss on a call. We can use the mailing list in the mean time. Chris From elizabeth.frausto at gmail.com Fri Jun 14 02:49:32 2013 From: elizabeth.frausto at gmail.com (=?ISO-8859-1?Q?Silvia_Elizabeth_Frausto_Del_R=EDo?=) Date: Thu, 13 Jun 2013 21:49:32 -0500 Subject: [cdwg] unsuscribe me please Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.a.jones at intel.com Fri Jun 14 13:20:27 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 14 Jun 2013 13:20:27 +0000 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: <5608FE2F-BE59-4E91-A8FE-ED5AE9518D0B@xyratex.com> Message-ID: Well, both LU-3472 and LU-3473 have been uploaded since I conducted my analysis yesterday. I see that a number of others have been touched in the past 24 hours also perhaps their status has changed also. I also see patches targeted for maintenance branches in this list which are not master patches. It would be helpful if you could be specific about what you feel has been omitted rather than expecting me to guess - thanks! On 6/14/13 3:55 AM, "Vitaly Fertman" wrote: >Peter, > >why don't you use this search: > >http://review.whamcloud.com/#q,status:open+message:xyratex+-Verified-1+-Ve >rified-2+-CodeReview-1+-CodeReview-2,n,z > >it shows some more patches > >> From: Jones, Peter A >> Date: 13 June 2013 19:41 >> Subject: Re: [cdwg] Pending items to land on Lustre Tree >> To: Kevin Canady , "Christopher J. Morrone" >> >> Cc: "'cdwg at lists.opensfs.org' (cdwg at lists.opensfs.org)" >>, Tommy Minyard >> >> >> Hi Kevin >> >> I appreciate that you will be busy with ISC looming and so likely won't >>get to the review of the patches for a while. I had a quieter morning so >>I did an audit of the Xyratex master patches. >> >> I found that there are three patches ready to land - LU3096, LU-2212 >>and LU-2479. Oleg has been getting caught up with landings to master now >>that 2.4 is GA and I have asked him to prioritize these three for >>consideration. >> >> In addition, there are six patches are waiting for reviews from Intel >>engineers. Three of these relate to new features(LU-2488, LU-2869, and >>LU-2854) and three are bugs (LU-3399, LU-3277, and LU-1715). All feature >>landings have been on hold during the feature freeze, but now those >>should start moving. Some of the bugs have been waiting a few weeks for >>reviews ­ sorry about that, but engineers such as Oleg and Andreas are >>very busy. We'll get some attention to these as soon as possible and the >>reason that they are so overloaded is that their feedback is worth the >>wait :-) >> >> There is one patch (LU-3155) just uploaded yesterday that is still >>running through regression testing >> >> One patch(LU-901) failed regression tests and the Intel engineer >>responsible has not yet advised whether the failure is related to the >>proposed patch or not ­ sorry about that! I have followed up with the >>engineer to ensure that this is made clear in the ticket what the next >>steps should be. >> >> Finally, I discovered that a patch for LU-1409 had slipped through the >>net because it had been uploaded into gerrit against a closed JIRA >>ticket with no associated comment being made in the JIRA ticket and no >>reviewers being added. It's not quite clear to me whether this is follow >>on work or really a new issue. I have posted a question on the JIRA >>ticket with a view to getting this cleared up and we will take action >>accordingly. >> >> As Chris suggested, there are also a number of other patches which are >>waiting for revisions or clarifications from Xyratex engineers. As part >>of your internal review it would be great to mark those which are not >>relevant to current master to be marked as deprecated so that we can >>focus on those patches that are important. >> >> Thanks >> >> Peter >> >> >> On 6/11/13 11:12 AM, "Kevin Canady" >>> wrote: >> >> Hi Chris, >> Thank you very much, great feedback. I agree with your sentiments that >>keeping the machine moving requires proper submissions. Thus, i have >>asked us to review internally prior to truly making this an issue for >>CDWG to discuss. My motivation is to keep this transparent to encourage >>others to also contribute. Xyratex has made many submissions which have >>landed and will continue to do so. I'm sure the actual count is going >>to change since it will remain fluid as new fixes and submissions are >>made ready and upstreamed. It's a constant effort. The point of the >>number is that it was large enough to warrant some attention. The action >>for the moment is ours to clarify and clean up and then confirm to move >>forward. >> >> As you rightly point out we should not put undue burden on gatekeeping >>or release to clean up work of others so it is important process is >>followed. The goal is, if done properly, quality submissions will land >>quickly and be the benefit of all. >> >> Thank you again for the feedback, I'm encouraged rather than feeling >>pain, just want to make sure we are going down the right path, in the >>right forum. >> >> Many thanks, look forward to picking this up in a few weeks after ISC. >> >> Cheers, >> Kevin >> >> >> P. Kevin Canady >> Director, Business Development Lustre and HPC Services >> kevin_canady at xyratex.com >> 415.505.7701 >> >> >> >> On Jun 11, 2013, at 10:56 AM, "Christopher J. Morrone" >>> wrote: >> >> Kevin, >> >> One thing that we should probably clarify is that you do not >>necessarily have "65 items which are pending landing". You may have 65 >>items submitted to the patch review system, but that doesn't mean that >>they are pending landing yet. I would say that a patch is only in the >>"pending landing" state when it has gotten all required positive >>reviews, and had the gatekeeper reviewer assigned. >> >> Pushing our patches to the review system is easy; addressing all of the >>faults in our patches that are found by the reviewers is often difficult >>and/or time consuming. But this process of review is one of the best >>tools that we have to maintain and improve the code quality in lustre. >> >> I would suggest that the first step for your guys are: >> >> 1) Complete all work required by the patch reviewers. >> >> 2) Refresh all patches that no longer apply cleanly. >> >> 3) If steps 1 and 2 are complete, and the patch is not getting >>attention, have a conversation in the associated Jira ticket. >> >> 4) Finally, if having a conversation in Jira does not achieve >>satisfaction, bring the issue to the attention of the CDWG through the >>cdwg mailing list. >> >> I have spotted several patches from Xyratex that haven't met steps 1 or >>2, let alone 3. On one recent patch, a Xyratex developer flat out >>refused to rebase an out of date patch, and insisted that Intel do it >>for them. That attitude needs to be addressed. It is the patch >>submitter's responsibility to get his patch into proper shape for >>landing, not the patch reviewer's responsibility. >> >> Yes, this process can be long and even tedious at times. I understand. >> I feel your pain. I have had simple patches that I have needed to >>rebase several times because of other patches that landed before mine, >>introducing a conflict for my patch. But that is just a natural result >>of many people working together in the same areas of code. >> >> We can't possibly shift all of that work work up the chain to the top >>reviewers or the gatekeeper. That would be a fundamentally unscalable >>approach to software development. They can't possibly handle the work >>load. That is why the patch submitter must take on the responsibility >>of seeing the patch through to 100% completion. >> >> So I could be wrong, but I suspect that a much smaller number of those >>65 patches that you mentioned are really ready to be discussed by the >>broader CDWG. >> >> But once your internal review is complete, and you have completed the >>steps that I've listed, we are happy to discuss any patches that you >>feel are being ignored! >> >> Chris >> >> On 06/11/2013 09:34 AM, Kevin Canady wrote: >> Chris, Peter and anyone else appropriate. >> >> I'm looking for suggestions on how to review and proceed with items >>awaiting landing. Some of them are over 24months old. I have a list of >>65 items which are pending landing. Hopefully these contributions will >>further enhance and improve the Lustre experience for everyone. I've >>requested, first, an internal review to make sure all contributions are >>valid, complete and have been properly submitted. >> >> Once that is done what is the best course for reviewing these items in >>order to bring them to a close (landed)? >> >> Should we post the list with ticket numbers to CDWG? >> >> Appreciate thoughts and suggestions. >> Kevin >> >> >> P. Kevin Canady >> Director, Business Development Lustre and HPC Services >> kevin_canady at xyratex.com >> O: 510-687-5475 >> C: 415.505.7701 (best) >> >> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> >> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> >> >> >> -- >> >> John Forgan >> Senior Software Engineering Manager >> Xyratex >> Office : +44 (0)2392 496819 >> Mobile: +44 (0)7738 136207 >> john_forgan at xyratex.com >> www.xyratex.com > >-- >Vitaly > From john_forgan at xyratex.com Fri Jun 14 13:45:26 2013 From: john_forgan at xyratex.com (John Forgan) Date: Fri, 14 Jun 2013 14:45:26 +0100 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: References: <5608FE2F-BE59-4E91-A8FE-ED5AE9518D0B@xyratex.com> Message-ID: Hi Peter, I'll work with the team to get a consolidated list of any tickets that we think might need some attention, rather than feeding you bits of information piecemeal. Thanks for the understanding. Best regards John On 14 June 2013 14:20, Jones, Peter A wrote: > Well, both LU-3472 and LU-3473 have been uploaded since I conducted my > analysis yesterday. I see that a number of others have been touched in the > past 24 hours also perhaps their status has changed also. I also see > patches targeted for maintenance branches in this list which are not > master patches. It would be helpful if you could be specific about what > you feel has been omitted rather than expecting me to guess - thanks! > > On 6/14/13 3:55 AM, "Vitaly Fertman" wrote: > > >Peter, > > > >why don't you use this search: > > > > > http://review.whamcloud.com/#q,status:open+message:xyratex+-Verified-1+-Ve > >rified-2+-CodeReview-1+-CodeReview-2,n,z > > > >it shows some more patches > > > >> From: Jones, Peter A > >> Date: 13 June 2013 19:41 > >> Subject: Re: [cdwg] Pending items to land on Lustre Tree > >> To: Kevin Canady , "Christopher J. Morrone" > >> > >> Cc: "'cdwg at lists.opensfs.org' (cdwg at lists.opensfs.org)" > >>, Tommy Minyard > >> > >> > >> Hi Kevin > >> > >> I appreciate that you will be busy with ISC looming and so likely won't > >>get to the review of the patches for a while. I had a quieter morning so > >>I did an audit of the Xyratex master patches. > >> > >> I found that there are three patches ready to land - LU3096, LU-2212 > >>and LU-2479. Oleg has been getting caught up with landings to master now > >>that 2.4 is GA and I have asked him to prioritize these three for > >>consideration. > >> > >> In addition, there are six patches are waiting for reviews from Intel > >>engineers. Three of these relate to new features(LU-2488, LU-2869, and > >>LU-2854) and three are bugs (LU-3399, LU-3277, and LU-1715). All feature > >>landings have been on hold during the feature freeze, but now those > >>should start moving. Some of the bugs have been waiting a few weeks for > >>reviews ­ sorry about that, but engineers such as Oleg and Andreas are > >>very busy. We'll get some attention to these as soon as possible and the > >>reason that they are so overloaded is that their feedback is worth the > >>wait :-) > >> > >> There is one patch (LU-3155) just uploaded yesterday that is still > >>running through regression testing > >> > >> One patch(LU-901) failed regression tests and the Intel engineer > >>responsible has not yet advised whether the failure is related to the > >>proposed patch or not ­ sorry about that! I have followed up with the > >>engineer to ensure that this is made clear in the ticket what the next > >>steps should be. > >> > >> Finally, I discovered that a patch for LU-1409 had slipped through the > >>net because it had been uploaded into gerrit against a closed JIRA > >>ticket with no associated comment being made in the JIRA ticket and no > >>reviewers being added. It's not quite clear to me whether this is follow > >>on work or really a new issue. I have posted a question on the JIRA > >>ticket with a view to getting this cleared up and we will take action > >>accordingly. > >> > >> As Chris suggested, there are also a number of other patches which are > >>waiting for revisions or clarifications from Xyratex engineers. As part > >>of your internal review it would be great to mark those which are not > >>relevant to current master to be marked as deprecated so that we can > >>focus on those patches that are important. > >> > >> Thanks > >> > >> Peter > >> > >> > >> On 6/11/13 11:12 AM, "Kevin Canady" > >>> wrote: > >> > >> Hi Chris, > >> Thank you very much, great feedback. I agree with your sentiments that > >>keeping the machine moving requires proper submissions. Thus, i have > >>asked us to review internally prior to truly making this an issue for > >>CDWG to discuss. My motivation is to keep this transparent to encourage > >>others to also contribute. Xyratex has made many submissions which have > >>landed and will continue to do so. I'm sure the actual count is going > >>to change since it will remain fluid as new fixes and submissions are > >>made ready and upstreamed. It's a constant effort. The point of the > >>number is that it was large enough to warrant some attention. The action > >>for the moment is ours to clarify and clean up and then confirm to move > >>forward. > >> > >> As you rightly point out we should not put undue burden on gatekeeping > >>or release to clean up work of others so it is important process is > >>followed. The goal is, if done properly, quality submissions will land > >>quickly and be the benefit of all. > >> > >> Thank you again for the feedback, I'm encouraged rather than feeling > >>pain, just want to make sure we are going down the right path, in the > >>right forum. > >> > >> Many thanks, look forward to picking this up in a few weeks after ISC. > >> > >> Cheers, > >> Kevin > >> > >> > >> P. Kevin Canady > >> Director, Business Development Lustre and HPC Services > >> kevin_canady at xyratex.com > >> 415.505.7701 > >> > >> > >> > >> On Jun 11, 2013, at 10:56 AM, "Christopher J. Morrone" > >>> wrote: > >> > >> Kevin, > >> > >> One thing that we should probably clarify is that you do not > >>necessarily have "65 items which are pending landing". You may have 65 > >>items submitted to the patch review system, but that doesn't mean that > >>they are pending landing yet. I would say that a patch is only in the > >>"pending landing" state when it has gotten all required positive > >>reviews, and had the gatekeeper reviewer assigned. > >> > >> Pushing our patches to the review system is easy; addressing all of the > >>faults in our patches that are found by the reviewers is often difficult > >>and/or time consuming. But this process of review is one of the best > >>tools that we have to maintain and improve the code quality in lustre. > >> > >> I would suggest that the first step for your guys are: > >> > >> 1) Complete all work required by the patch reviewers. > >> > >> 2) Refresh all patches that no longer apply cleanly. > >> > >> 3) If steps 1 and 2 are complete, and the patch is not getting > >>attention, have a conversation in the associated Jira ticket. > >> > >> 4) Finally, if having a conversation in Jira does not achieve > >>satisfaction, bring the issue to the attention of the CDWG through the > >>cdwg mailing list. > >> > >> I have spotted several patches from Xyratex that haven't met steps 1 or > >>2, let alone 3. On one recent patch, a Xyratex developer flat out > >>refused to rebase an out of date patch, and insisted that Intel do it > >>for them. That attitude needs to be addressed. It is the patch > >>submitter's responsibility to get his patch into proper shape for > >>landing, not the patch reviewer's responsibility. > >> > >> Yes, this process can be long and even tedious at times. I understand. > >> I feel your pain. I have had simple patches that I have needed to > >>rebase several times because of other patches that landed before mine, > >>introducing a conflict for my patch. But that is just a natural result > >>of many people working together in the same areas of code. > >> > >> We can't possibly shift all of that work work up the chain to the top > >>reviewers or the gatekeeper. That would be a fundamentally unscalable > >>approach to software development. They can't possibly handle the work > >>load. That is why the patch submitter must take on the responsibility > >>of seeing the patch through to 100% completion. > >> > >> So I could be wrong, but I suspect that a much smaller number of those > >>65 patches that you mentioned are really ready to be discussed by the > >>broader CDWG. > >> > >> But once your internal review is complete, and you have completed the > >>steps that I've listed, we are happy to discuss any patches that you > >>feel are being ignored! > >> > >> Chris > >> > >> On 06/11/2013 09:34 AM, Kevin Canady wrote: > >> Chris, Peter and anyone else appropriate. > >> > >> I'm looking for suggestions on how to review and proceed with items > >>awaiting landing. Some of them are over 24months old. I have a list of > >>65 items which are pending landing. Hopefully these contributions will > >>further enhance and improve the Lustre experience for everyone. I've > >>requested, first, an internal review to make sure all contributions are > >>valid, complete and have been properly submitted. > >> > >> Once that is done what is the best course for reviewing these items in > >>order to bring them to a close (landed)? > >> > >> Should we post the list with ticket numbers to CDWG? > >> > >> Appreciate thoughts and suggestions. > >> Kevin > >> > >> > >> P. Kevin Canady > >> Director, Business Development Lustre and HPC Services > >> kevin_canady at xyratex.com > >> O: 510-687-5475 > >> C: 415.505.7701 (best) > >> > >> > >> > >> _______________________________________________ > >> cdwg mailing list > >> cdwg at lists.opensfs.org > >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > >> > >> > >> > >> _______________________________________________ > >> cdwg mailing list > >> cdwg at lists.opensfs.org > >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > >> > >> > >> > >> -- > >> > >> John Forgan > >> Senior Software Engineering Manager > >> Xyratex > >> Office : +44 (0)2392 496819 > >> Mobile: +44 (0)7738 136207 > >> john_forgan at xyratex.com > >> www.xyratex.com > > > >-- > >Vitaly > > > > -- John Forgan Senior Software Engineering Manager Xyratex Office : +44 (0)2392 496819 Mobile: +44 (0)7738 136207 *john_forgan at xyratex.com *www.xyratex.com -- ------------------------------ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.a.jones at intel.com Fri Jun 14 13:59:35 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 14 Jun 2013 13:59:35 +0000 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: Message-ID: Thanks John! Piecemeal information would be fine as long as it is specific. :-) On 6/14/13 6:45 AM, "John Forgan" > wrote: Hi Peter, I'll work with the team to get a consolidated list of any tickets that we think might need some attention, rather than feeding you bits of information piecemeal. Thanks for the understanding. Best regards John On 14 June 2013 14:20, Jones, Peter A > wrote: Well, both LU-3472 and LU-3473 have been uploaded since I conducted my analysis yesterday. I see that a number of others have been touched in the past 24 hours also perhaps their status has changed also. I also see patches targeted for maintenance branches in this list which are not master patches. It would be helpful if you could be specific about what you feel has been omitted rather than expecting me to guess - thanks! On 6/14/13 3:55 AM, "Vitaly Fertman" > wrote: >Peter, > >why don't you use this search: > >http://review.whamcloud.com/#q,status:open+message:xyratex+-Verified-1+-Ve >rified-2+-CodeReview-1+-CodeReview-2,n,z > >it shows some more patches > >> From: Jones, Peter A > >> Date: 13 June 2013 19:41 >> Subject: Re: [cdwg] Pending items to land on Lustre Tree >> To: Kevin Canady >, "Christopher J. Morrone" >>> >> Cc: "'cdwg at lists.opensfs.org' (cdwg at lists.opensfs.org)" >>>, Tommy Minyard > >> >> >> Hi Kevin >> >> I appreciate that you will be busy with ISC looming and so likely won't >>get to the review of the patches for a while. I had a quieter morning so >>I did an audit of the Xyratex master patches. >> >> I found that there are three patches ready to land - LU3096, LU-2212 >>and LU-2479. Oleg has been getting caught up with landings to master now >>that 2.4 is GA and I have asked him to prioritize these three for >>consideration. >> >> In addition, there are six patches are waiting for reviews from Intel >>engineers. Three of these relate to new features(LU-2488, LU-2869, and >>LU-2854) and three are bugs (LU-3399, LU-3277, and LU-1715). All feature >>landings have been on hold during the feature freeze, but now those >>should start moving. Some of the bugs have been waiting a few weeks for >>reviews ­ sorry about that, but engineers such as Oleg and Andreas are >>very busy. We'll get some attention to these as soon as possible and the >>reason that they are so overloaded is that their feedback is worth the >>wait :-) >> >> There is one patch (LU-3155) just uploaded yesterday that is still >>running through regression testing >> >> One patch(LU-901) failed regression tests and the Intel engineer >>responsible has not yet advised whether the failure is related to the >>proposed patch or not ­ sorry about that! I have followed up with the >>engineer to ensure that this is made clear in the ticket what the next >>steps should be. >> >> Finally, I discovered that a patch for LU-1409 had slipped through the >>net because it had been uploaded into gerrit against a closed JIRA >>ticket with no associated comment being made in the JIRA ticket and no >>reviewers being added. It's not quite clear to me whether this is follow >>on work or really a new issue. I have posted a question on the JIRA >>ticket with a view to getting this cleared up and we will take action >>accordingly. >> >> As Chris suggested, there are also a number of other patches which are >>waiting for revisions or clarifications from Xyratex engineers. As part >>of your internal review it would be great to mark those which are not >>relevant to current master to be marked as deprecated so that we can >>focus on those patches that are important. >> >> Thanks >> >> Peter >> >> >> On 6/11/13 11:12 AM, "Kevin Canady" >>>> wrote: >> >> Hi Chris, >> Thank you very much, great feedback. I agree with your sentiments that >>keeping the machine moving requires proper submissions. Thus, i have >>asked us to review internally prior to truly making this an issue for >>CDWG to discuss. My motivation is to keep this transparent to encourage >>others to also contribute. Xyratex has made many submissions which have >>landed and will continue to do so. I'm sure the actual count is going >>to change since it will remain fluid as new fixes and submissions are >>made ready and upstreamed. It's a constant effort. The point of the >>number is that it was large enough to warrant some attention. The action >>for the moment is ours to clarify and clean up and then confirm to move >>forward. >> >> As you rightly point out we should not put undue burden on gatekeeping >>or release to clean up work of others so it is important process is >>followed. The goal is, if done properly, quality submissions will land >>quickly and be the benefit of all. >> >> Thank you again for the feedback, I'm encouraged rather than feeling >>pain, just want to make sure we are going down the right path, in the >>right forum. >> >> Many thanks, look forward to picking this up in a few weeks after ISC. >> >> Cheers, >> Kevin >> >> >> P. Kevin Canady >> Director, Business Development Lustre and HPC Services >> kevin_canady at xyratex.com> >> 415.505.7701 >> >> >> >> On Jun 11, 2013, at 10:56 AM, "Christopher J. Morrone" >>>> wrote: >> >> Kevin, >> >> One thing that we should probably clarify is that you do not >>necessarily have "65 items which are pending landing". You may have 65 >>items submitted to the patch review system, but that doesn't mean that >>they are pending landing yet. I would say that a patch is only in the >>"pending landing" state when it has gotten all required positive >>reviews, and had the gatekeeper reviewer assigned. >> >> Pushing our patches to the review system is easy; addressing all of the >>faults in our patches that are found by the reviewers is often difficult >>and/or time consuming. But this process of review is one of the best >>tools that we have to maintain and improve the code quality in lustre. >> >> I would suggest that the first step for your guys are: >> >> 1) Complete all work required by the patch reviewers. >> >> 2) Refresh all patches that no longer apply cleanly. >> >> 3) If steps 1 and 2 are complete, and the patch is not getting >>attention, have a conversation in the associated Jira ticket. >> >> 4) Finally, if having a conversation in Jira does not achieve >>satisfaction, bring the issue to the attention of the CDWG through the >>cdwg mailing list. >> >> I have spotted several patches from Xyratex that haven't met steps 1 or >>2, let alone 3. On one recent patch, a Xyratex developer flat out >>refused to rebase an out of date patch, and insisted that Intel do it >>for them. That attitude needs to be addressed. It is the patch >>submitter's responsibility to get his patch into proper shape for >>landing, not the patch reviewer's responsibility. >> >> Yes, this process can be long and even tedious at times. I understand. >> I feel your pain. I have had simple patches that I have needed to >>rebase several times because of other patches that landed before mine, >>introducing a conflict for my patch. But that is just a natural result >>of many people working together in the same areas of code. >> >> We can't possibly shift all of that work work up the chain to the top >>reviewers or the gatekeeper. That would be a fundamentally unscalable >>approach to software development. They can't possibly handle the work >>load. That is why the patch submitter must take on the responsibility >>of seeing the patch through to 100% completion. >> >> So I could be wrong, but I suspect that a much smaller number of those >>65 patches that you mentioned are really ready to be discussed by the >>broader CDWG. >> >> But once your internal review is complete, and you have completed the >>steps that I've listed, we are happy to discuss any patches that you >>feel are being ignored! >> >> Chris >> >> On 06/11/2013 09:34 AM, Kevin Canady wrote: >> Chris, Peter and anyone else appropriate. >> >> I'm looking for suggestions on how to review and proceed with items >>awaiting landing. Some of them are over 24months old. I have a list of >>65 items which are pending landing. Hopefully these contributions will >>further enhance and improve the Lustre experience for everyone. I've >>requested, first, an internal review to make sure all contributions are >>valid, complete and have been properly submitted. >> >> Once that is done what is the best course for reviewing these items in >>order to bring them to a close (landed)? >> >> Should we post the list with ticket numbers to CDWG? >> >> Appreciate thoughts and suggestions. >> Kevin >> >> >> P. Kevin Canady >> Director, Business Development Lustre and HPC Services >> kevin_canady at xyratex.com> >> O: 510-687-5475 >> C: 415.505.7701 (best) >> >> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org> >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> >> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> >> >> >> -- >> >> John Forgan >> Senior Software Engineering Manager >> Xyratex >> Office : +44 (0)2392 496819 >> Mobile: +44 (0)7738 136207 >> john_forgan at xyratex.com >> www.xyratex.com > >-- >Vitaly > -- John Forgan Senior Software Engineering Manager Xyratex Office : +44 (0)2392 496819 Mobile: +44 (0)7738 136207 john_forgan at xyratex.com www.xyratex.com ________________________________ For additional information including the registered office and the treatment of Xyratex confidential information please visit www.xyratex.com ________________________________ From vitaly_fertman at xyratex.com Fri Jun 14 10:55:33 2013 From: vitaly_fertman at xyratex.com (Vitaly Fertman) Date: Fri, 14 Jun 2013 14:55:33 +0400 Subject: [cdwg] Pending items to land on Lustre Tree In-Reply-To: References: <42B90EBB-4A5C-4587-8180-27C58FBE0B4C@xyratex.com> Message-ID: <5608FE2F-BE59-4E91-A8FE-ED5AE9518D0B@xyratex.com> Peter, why don't you use this search: http://review.whamcloud.com/#q,status:open+message:xyratex+-Verified-1+-Verified-2+-CodeReview-1+-CodeReview-2,n,z it shows some more patches > From: Jones, Peter A > Date: 13 June 2013 19:41 > Subject: Re: [cdwg] Pending items to land on Lustre Tree > To: Kevin Canady , "Christopher J. Morrone" > Cc: "'cdwg at lists.opensfs.org' (cdwg at lists.opensfs.org)" , Tommy Minyard > > > Hi Kevin > > I appreciate that you will be busy with ISC looming and so likely won't get to the review of the patches for a while. I had a quieter morning so I did an audit of the Xyratex master patches. > > I found that there are three patches ready to land - LU3096, LU-2212 and LU-2479. Oleg has been getting caught up with landings to master now that 2.4 is GA and I have asked him to prioritize these three for consideration. > > In addition, there are six patches are waiting for reviews from Intel engineers. Three of these relate to new features(LU-2488, LU-2869, and LU-2854) and three are bugs (LU-3399, LU-3277, and LU-1715). All feature landings have been on hold during the feature freeze, but now those should start moving. Some of the bugs have been waiting a few weeks for reviews – sorry about that, but engineers such as Oleg and Andreas are very busy. We'll get some attention to these as soon as possible and the reason that they are so overloaded is that their feedback is worth the wait :-) > > There is one patch (LU-3155) just uploaded yesterday that is still running through regression testing > > One patch(LU-901) failed regression tests and the Intel engineer responsible has not yet advised whether the failure is related to the proposed patch or not – sorry about that! I have followed up with the engineer to ensure that this is made clear in the ticket what the next steps should be. > > Finally, I discovered that a patch for LU-1409 had slipped through the net because it had been uploaded into gerrit against a closed JIRA ticket with no associated comment being made in the JIRA ticket and no reviewers being added. It's not quite clear to me whether this is follow on work or really a new issue. I have posted a question on the JIRA ticket with a view to getting this cleared up and we will take action accordingly. > > As Chris suggested, there are also a number of other patches which are waiting for revisions or clarifications from Xyratex engineers. As part of your internal review it would be great to mark those which are not relevant to current master to be marked as deprecated so that we can focus on those patches that are important. > > Thanks > > Peter > > > On 6/11/13 11:12 AM, "Kevin Canady" > wrote: > > Hi Chris, > Thank you very much, great feedback. I agree with your sentiments that keeping the machine moving requires proper submissions. Thus, i have asked us to review internally prior to truly making this an issue for CDWG to discuss. My motivation is to keep this transparent to encourage others to also contribute. Xyratex has made many submissions which have landed and will continue to do so. I'm sure the actual count is going to change since it will remain fluid as new fixes and submissions are made ready and upstreamed. It's a constant effort. The point of the number is that it was large enough to warrant some attention. The action for the moment is ours to clarify and clean up and then confirm to move forward. > > As you rightly point out we should not put undue burden on gatekeeping or release to clean up work of others so it is important process is followed. The goal is, if done properly, quality submissions will land quickly and be the benefit of all. > > Thank you again for the feedback, I'm encouraged rather than feeling pain, just want to make sure we are going down the right path, in the right forum. > > Many thanks, look forward to picking this up in a few weeks after ISC. > > Cheers, > Kevin > > > P. Kevin Canady > Director, Business Development Lustre and HPC Services > kevin_canady at xyratex.com > 415.505.7701 > > > > On Jun 11, 2013, at 10:56 AM, "Christopher J. Morrone" > wrote: > > Kevin, > > One thing that we should probably clarify is that you do not necessarily have "65 items which are pending landing". You may have 65 items submitted to the patch review system, but that doesn't mean that they are pending landing yet. I would say that a patch is only in the "pending landing" state when it has gotten all required positive reviews, and had the gatekeeper reviewer assigned. > > Pushing our patches to the review system is easy; addressing all of the faults in our patches that are found by the reviewers is often difficult and/or time consuming. But this process of review is one of the best tools that we have to maintain and improve the code quality in lustre. > > I would suggest that the first step for your guys are: > > 1) Complete all work required by the patch reviewers. > > 2) Refresh all patches that no longer apply cleanly. > > 3) If steps 1 and 2 are complete, and the patch is not getting attention, have a conversation in the associated Jira ticket. > > 4) Finally, if having a conversation in Jira does not achieve satisfaction, bring the issue to the attention of the CDWG through the cdwg mailing list. > > I have spotted several patches from Xyratex that haven't met steps 1 or 2, let alone 3. On one recent patch, a Xyratex developer flat out refused to rebase an out of date patch, and insisted that Intel do it for them. That attitude needs to be addressed. It is the patch submitter's responsibility to get his patch into proper shape for landing, not the patch reviewer's responsibility. > > Yes, this process can be long and even tedious at times. I understand. I feel your pain. I have had simple patches that I have needed to rebase several times because of other patches that landed before mine, introducing a conflict for my patch. But that is just a natural result of many people working together in the same areas of code. > > We can't possibly shift all of that work work up the chain to the top reviewers or the gatekeeper. That would be a fundamentally unscalable approach to software development. They can't possibly handle the work load. That is why the patch submitter must take on the responsibility of seeing the patch through to 100% completion. > > So I could be wrong, but I suspect that a much smaller number of those 65 patches that you mentioned are really ready to be discussed by the broader CDWG. > > But once your internal review is complete, and you have completed the steps that I've listed, we are happy to discuss any patches that you feel are being ignored! > > Chris > > On 06/11/2013 09:34 AM, Kevin Canady wrote: > Chris, Peter and anyone else appropriate. > > I'm looking for suggestions on how to review and proceed with items awaiting landing. Some of them are over 24months old. I have a list of 65 items which are pending landing. Hopefully these contributions will further enhance and improve the Lustre experience for everyone. I've requested, first, an internal review to make sure all contributions are valid, complete and have been properly submitted. > > Once that is done what is the best course for reviewing these items in order to bring them to a close (landed)? > > Should we post the list with ticket numbers to CDWG? > > Appreciate thoughts and suggestions. > Kevin > > > P. Kevin Canady > Director, Business Development Lustre and HPC Services > kevin_canady at xyratex.com > O: 510-687-5475 > C: 415.505.7701 (best) > > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > > > -- > > John Forgan > Senior Software Engineering Manager > Xyratex > Office : +44 (0)2392 496819 > Mobile: +44 (0)7738 136207 > john_forgan at xyratex.com > www.xyratex.com -- Vitaly From morrone2 at llnl.gov Fri Jun 14 20:44:01 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Fri, 14 Jun 2013 13:44:01 -0700 Subject: [cdwg] Completion of 2.5.0 Scoping Effort Message-ID: <51BB8091.2030600@llnl.gov> Hi folks, As Technical Rep. on the OpenSFS "tree contract" and head of the CDWG, I got together with Peter Jones and we went over all of the tickets that you guys suggested for scoping into Lustre 2.5.0. Each issue that we agreed is in scope for Lustre 2.5.0 has had the "Lustre 2.5.0" version added to its Jira ticket. I have summarized the state of scoping on the development-in-progress page: http://wiki.opensfs.org/Lustre_Community_Development_in_Progress That page also contains some convenient links into Jira. Please keep in mind that this list is _not_ a guarantee of work that will be completed for 2.5.0. This is just our best effort at planning a reasonable amount of work for 2.5.0. The scope will grow as bugs are reported and added to the list of things that need fixing for 2.5.0. The scope may also shrink as planned items make insufficient progress. If you think we missed something that really should be in 2.5.0, please make a case for its inclusion right here on this mailing list. We are happy to explain why we thought an item as not viable in the 2.5.0 time frame, and/or to reconsider if you think we made a mistake. Chris From morrone2 at llnl.gov Fri Jun 14 21:00:06 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Fri, 14 Jun 2013 14:00:06 -0700 Subject: [cdwg] Lustre 2.5.0 development schedule Message-ID: <51BB8456.5070405@llnl.gov> Hi folks, I started a new wiki page specific to Lustre 2.5.0 here: http://wiki.opensfs.org/Lustre_2.5.0 It contains a list of important dates, and helpful links to pages in the issue tracker. Chris From morrone2 at llnl.gov Tue Jun 18 21:35:11 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Tue, 18 Jun 2013 14:35:11 -0700 Subject: [cdwg] CANCELED: OpenSFS CDWG Call Message-ID: <51C0D28F.3080207@llnl.gov> Hi all, The CDWG on June 19 is canceled due to ISC'13. Take any topics to the mailing list. Regards, Chris From uja at ornl.gov Fri Jun 21 14:31:29 2013 From: uja at ornl.gov (James A Simmons) Date: Fri, 21 Jun 2013 10:31:29 -0400 Subject: [cdwg] Alternative non accelerated checksums Message-ID: <1371825089.8955.35.camel@bohr.ornl.gov> Hello Recently I have been doing an evaluation of the performance of check summing in the Lustre code base. From the results you can see it can be very expensive when you lack hardware acceleration. Unfortunately we have some platforms were their is a high cost but check summing is a requirement. Since the best case for non accelerated is not good enough I have looked into other hashing type algorithms to see if they can meet the communities needs. Besides the core algorithms I have added a few of my own to see how they measure up. We have csum which is your normal IP Header check sum. A 32 bit version of murmur3 was implemented. I used the jhash.h from linux to implement jenkins and lastly siphash was implemented. Siphash author claims it to be more secure algorithm in the same category as md5 but with much better speeds. I have tested against four systems. The first set of test is for non cryptographic hashes and the second is for the cryptographic set. AMD Opteron(tm) Processor 6168 @ 1.9GHz stepping 1 Lustre: Crypto hash algorithm adler32 speed = 754 MB/s Lustre: Crypto hash algorithm csum speed = 1834 MB/s Lustre: Crypto hash algorithm murmur speed = 1093 MB/s Lustre: Crypto hash algorithm jenkins speed = 763 MB/s Lustre: Crypto hash algorithm md5 speed = 306 MB/s Lustre: Crypto hash algorithm sha1 speed = 123 MB/s Lustre: Crypto hash algorithm siphash speed = 593 MB/s AMD Opteron(TM) Processor 6274 @ 2.2GHz stepping 2 Lustre: Crypto hash algorithm adler32 speed = 670 MB/s Lustre: Crypto hash algorithm csum speed = 802 MB/s Lustre: Crypto hash algorithm murmur speed = 1511 MB/s Lustre: Crypto hash algorithm jenkins speed = 614 MB/s Lustre: Crypto hash algorithm md5 speed = 309 MB/s Lustre: Crypto hash algorithm sha1 speed = 118 MB/s Lustre: Crypto hash algorithm siphash speed = 669 MB/s Intel(R) Xeon(R) CPU E5520 @ 2.27GHz stepping 05 Lustre: Crypto hash algorithm adler32 speed = 836 MB/s Lustre: Crypto hash algorithm csum speed = 3639 MB/s Lustre: Crypto hash algorithm murmur speed = 1261 MB/s Lustre: Crypto hash algorithm jenkins speed = 766 MB/s Lustre: Crypto hash algorithm md5 speed = 265 MB/s Lustre: Crypto hash algorithm sha1 speed = 108 MB/s Lustre: Crypto hash algorithm sha256 speed = 75 MB/s Lustre: Crypto hash algorithm sha384 speed = 105 MB/s Lustre: Crypto hash algorithm sha512 speed = 105 MB/s Lustre: Crypto hash algorithm siphash speed = 570 MB/s Intel(R) Xeon(R) CPU E5-2603 0 @ 1.80GHz stepping 07 Lustre: Crypto hash algorithm adler32 speed = 1476 MB/s Lustre: Crypto hash algorithm csum speed = 1769 MB/s Lustre: Crypto hash algorithm murmur speed = 1243 MB/s Lustre: Crypto hash algorithm jenkins speed = 956 MB/s Lustre: Crypto hash algorithm md5 speed = 277 MB/s Lustre: Crypto hash algorithm sha1 speed = 118 MB/s Lustre: Crypto hash algorithm sha256 speed = 75 MB/s Lustre: Crypto hash algorithm sha384 speed = 112 MB/s Lustre: Crypto hash algorithm sha512 speed = 114 MB/s Lustre: Crypto hash algorithm siphash speed = 562 MB/s >From the data so far you can see when you compare siphash to shaX and md5 it is a clear winning in performance for the cryptographic hashes. For the non cryptographic hashes it's the IP check sum and murmur3 that does the best. This version of murmur3 only generates 32 check sums but their exist a 128 bit version that is suppose to be faster. It could be worth while to explore. The IP check sum from the linux kernel is assembly optimized but my additional algorithms are generic C. If done right we could speed up murmur3. The final question is the Lustre community interested in the new algorithms? If so I can push forward that work. From andreas.dilger at intel.com Fri Jun 21 18:12:00 2013 From: andreas.dilger at intel.com (Dilger, Andreas) Date: Fri, 21 Jun 2013 18:12:00 +0000 Subject: [cdwg] Alternative non accelerated checksums In-Reply-To: <1371825089.8955.35.camel@bohr.ornl.gov> References: <1371825089.8955.35.camel@bohr.ornl.gov> Message-ID: <37488011-A99E-41A7-9F97-99016BC03787@intel.com> On 2013-06-21, at 8:34, "James A Simmons" wrote: > Recently I have been doing an evaluation of the performance of check > summing in the Lustre code base. From the results you can see it can be > very expensive when you lack hardware acceleration. Unfortunately > we have some platforms were their is a high cost but check summing > is a requirement. It is also important to consider what checksum algorithm is used on the server, since the server will have to do the checksumming for all of the clients. > Besides the core algorithms I have added a few of my own to > see how they measure up. We have csum which is your normal IP Header > check sum. The IP header checksum is only 16-bit, so it is only suitable for a small amount of data. It is definitely not suitable for 1MB or 4MB RPC sizes. > For the non cryptographic hashes it's the IP check sum and murmur3 > that does the best. This version of murmur3 only generates 32 check > sums but their exist a 128 bit version that is suppose to be faster. > It could be worth while to explore. The IP check sum from the linux > kernel is assembly optimized but my additional algorithms are generic > C. You should test with the kernel cryptoapi code, since AFAIK there are assembly versions of the common algorithms already. Check out how the libcfs code is already handling the crc32 code - it benchmarks each algorithm at startup and dumps the results in the Lustre debug log. > The final question is the Lustre community interested in the new > algorithms? If so I can push forward that work. I'm not against it if there are significant improvements to be had. It surprises me that newer CPUs do not have hardware-accelerated checksums of some sort. Is it just that the assembly versions have not been implemented in the kernels that Lustre is running on? Could they be implemented in libcfs as was done with crc32 and then submitted to the upstream kernel (so everyone benefits and we don't have to maintain them forever)? Cheers, Andreas From peter.a.jones at intel.com Fri Jun 21 22:17:51 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Fri, 21 Jun 2013 22:17:51 +0000 Subject: [cdwg] Lustre 2.5 update - June 21st 2013 Message-ID: Hi there Here is an update on the Lustre 2.5 release. Landings ======== -A number of landings made - see http://git.whamcloud.com/?p=fs/lustre-release.git;a=shortlog;h=refs/heads/master Testing ======= - Testing on the 2.4.51 tag is underway Blockers ======== -Full list available at https://jira.hpdd.intel.com/issues/?jql=project%20%3D%20LU%20AND%20fixVersion%20%3D%20%22Lustre%202.5.0%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20key%20DESC -If there are any issues not presently marked as blockers that you believe should be, please let me know Other ===== * We are trialling using the Fix In Release field for the 2.5 release to track work hoped to be included in the release; this means that a fuller picture of the progress on the release can be viewed at https://jira.hpdd.intel.com/browse/LU/fixforversion/10295#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel -Feature Freeze is July 31st; any features that you hope to include in this release should be uploaded into gerrit in the next week or two to allow sufficient time for testing and reviews Thanks Peter From simmonsja at ornl.gov Wed Jun 26 12:23:31 2013 From: simmonsja at ornl.gov (James A Simmons) Date: Wed, 26 Jun 2013 08:23:31 -0400 Subject: [cdwg] Alternative non accelerated checksums In-Reply-To: <37488011-A99E-41A7-9F97-99016BC03787@intel.com> References: <1371825089.8955.35.camel@bohr.ornl.gov> <37488011-A99E-41A7-9F97-99016BC03787@intel.com> Message-ID: <1372249411.871.1256.camel@bohr.ornl.gov> > > Besides the core algorithms I have added a few of my own to > > see how they measure up. We have csum which is your normal IP Header > > check sum. > > The IP header checksum is only 16-bit, so it is only suitable for a small > amount of data. It is definitely not suitable for 1MB or 4MB RPC sizes. The size is just one factor making it vulnerable to collisions. The data position in the stream is not taking into consideration. Their are many papers on its weakness. > > For the non cryptographic hashes it's the IP check sum and murmur3 > > that does the best. This version of murmur3 only generates 32 check > > sums but their exist a 128 bit version that is suppose to be faster. > > It could be worth while to explore. The IP check sum from the linux > > kernel is assembly optimized but my additional algorithms are generic > > C. > > You should test with the kernel cryptoapi code, since AFAIK there are > assembly versions of the common algorithms already. Check out how the > libcfs code is already handling the crc32 code - it benchmarks each > algorithm at startup and dumps the results in the Lustre debug log. Currently the most useful optimized algorithms are in the 3.10-rcX kernels. I have only run lustre up to a linux 3.9.4 kernel so far. My first runs at collect data has been with the Lustre debug logs as well as tcrypt. > > The final question is the Lustre community interested in the new > > algorithms? If so I can push forward that work. > > I'm not against it if there are significant improvements to be had. Out of the test algorithms I implemented I would say siphash might be interesting to the UI guys. > It surprises me that newer CPUs do not have hardware-accelerated checksums > of some sort. Is it just that the assembly versions have not been implemented > in the kernels that Lustre is running on? Could they be implemented in libcfs > as was done with crc32 and then submitted to the upstream kernel (so everyone > benefits and we don't have to maintain them forever)? We have some production systems that only support up to SSE3 so we can't take advantage of any hardware acceleration for crc32 or crc32c. Down the line I will most likely need to implement this. From bryan.cote at terascala.com Thu Jun 27 15:01:42 2013 From: bryan.cote at terascala.com (Bryan Cote) Date: Thu, 27 Jun 2013 15:01:42 +0000 Subject: [cdwg] Maintenance releaase status of 2.5/2.4 Message-ID: <651dd0cdb6af4a909a6586aefe434790@CO1PR06MB062.namprd06.prod.outlook.com> Hello, Did we get consensus on whether 2.5 will be a maintenance release, and if so, what is the impact on 2.4? ==Bryan ______________________________________________________________________________ Bryan R. Cote | Sr. Product Manager M 603.557.3568 | P 617.722.0090 Ext. 302 | F 617.722.6060 100 North Washington Street | Boston, MA 02114 [cid:image002.jpg at 01CDFB24.4A1E3320] www.terascala.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1529 bytes Desc: image001.jpg URL: From morrone2 at llnl.gov Thu Jun 27 18:13:09 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Thu, 27 Jun 2013 11:13:09 -0700 Subject: [cdwg] Maintenance releaase status of 2.5/2.4 In-Reply-To: <651dd0cdb6af4a909a6586aefe434790@CO1PR06MB062.namprd06.prod.outlook.com> References: <651dd0cdb6af4a909a6586aefe434790@CO1PR06MB062.namprd06.prod.outlook.com> Message-ID: <51CC80B5.7080607@llnl.gov> Bryan, We certainly have consensus among the small number of organizations that bothered to reply. This will be on the Agenda for next Wednesday's call. When we officially announce that 2.5 will be a long term maintenance release, the we will explain that the maintenance period for 2.4 has been shortened dramatically. No longer should folks expect that 2.4 is a branch that will be supported for years. Instead its maintenance window might be only as long as it takes to get 2.5.0 released. But we haven't discussed the exact date to advertise as the cut off. Chris On 06/27/2013 08:01 AM, Bryan Cote wrote: > Hello, > > Did we get consensus on whether 2.5 will be a maintenance release, and > if so, what is the impact on 2.4? > > ==Bryan > > *______________________________________________________________________________* > > *Bryan R. Cote **|**Sr. Product Manager * > > *M 603.557.3568**|**P 617.722.0090 Ext. 302 **|**F 617.722.6060* > > *100 North Washington Street **|**Boston, MA 02114* > > ** > > cid:image002.jpg at 01CDFB24.4A1E3320** > > *www.terascala.com * > > > > _______________________________________________ > cdwg mailing list > cdwg at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > From spitzcor at cray.com Thu Jun 27 18:25:40 2013 From: spitzcor at cray.com (Cory Spitz) Date: Thu, 27 Jun 2013 18:25:40 +0000 Subject: [cdwg] Maintenance releaase status of 2.5/2.4 In-Reply-To: <51CC80B5.7080607@llnl.gov> Message-ID: Chris, What do you mean "when we officially announceŠ" I didn't realize that we had already decided. Do you mean to say, "*if* we officially announceŠ"? Thanks, -Cory On 6/27/13 1:13 PM, "Christopher J. Morrone" wrote: >Bryan, > >We certainly have consensus among the small number of organizations that >bothered to reply. This will be on the Agenda for next Wednesday's call. > >When we officially announce that 2.5 will be a long term maintenance >release, the we will explain that the maintenance period for 2.4 has >been shortened dramatically. No longer should folks expect that 2.4 is >a branch that will be supported for years. Instead its maintenance >window might be only as long as it takes to get 2.5.0 released. But we >haven't discussed the exact date to advertise as the cut off. > >Chris > >On 06/27/2013 08:01 AM, Bryan Cote wrote: >> Hello, >> >> Did we get consensus on whether 2.5 will be a maintenance release, and >> if so, what is the impact on 2.4? >> >> ==Bryan >> >> >>*________________________________________________________________________ >>______* >> >> *Bryan R. Cote **|**Sr. Product Manager * >> >> *M 603.557.3568**|**P 617.722.0090 Ext. 302 **|**F 617.722.6060* >> >> *100 North Washington Street **|**Boston, MA 02114* >> >> ** >> >> cid:image002.jpg at 01CDFB24.4A1E3320** >> >> *www.terascala.com * >> >> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> > >_______________________________________________ >cdwg mailing list >cdwg at lists.opensfs.org >http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From peter.a.jones at intel.com Thu Jun 27 18:40:46 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Thu, 27 Jun 2013 18:40:46 +0000 Subject: [cdwg] Maintenance releaase status of 2.5/2.4 In-Reply-To: <51CC80B5.7080607@llnl.gov> Message-ID: Chris To be clear, what was being discussed was which release stream would have _scheduled_ maintenance releases during 2014. Other codelines could still have ad-hoc maintenance releases and support is at the discretion of the support providers. Speaking as Intel, we have a number of customers moving forward with 2.4 and expect to be supporting them long term on that code line. Similarly, we have a number of customers interested in 2.5. We certainly would be willing to support customers on either release irrespective of what recommendation the CDWG makes on the scheduled releases. Peter On 6/27/13 11:13 AM, "Christopher J. Morrone" wrote: >Bryan, > >We certainly have consensus among the small number of organizations that >bothered to reply. This will be on the Agenda for next Wednesday's call. > >When we officially announce that 2.5 will be a long term maintenance >release, the we will explain that the maintenance period for 2.4 has >been shortened dramatically. No longer should folks expect that 2.4 is >a branch that will be supported for years. Instead its maintenance >window might be only as long as it takes to get 2.5.0 released. But we >haven't discussed the exact date to advertise as the cut off. > >Chris > >On 06/27/2013 08:01 AM, Bryan Cote wrote: >> Hello, >> >> Did we get consensus on whether 2.5 will be a maintenance release, and >> if so, what is the impact on 2.4? >> >> ==Bryan >> >> >>*________________________________________________________________________ >>______* >> >> *Bryan R. Cote **|**Sr. Product Manager * >> >> *M 603.557.3568**|**P 617.722.0090 Ext. 302 **|**F 617.722.6060* >> >> *100 North Washington Street **|**Boston, MA 02114* >> >> ** >> >> cid:image002.jpg at 01CDFB24.4A1E3320** >> >> *www.terascala.com * >> >> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> > >_______________________________________________ >cdwg mailing list >cdwg at lists.opensfs.org >http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From morrone2 at llnl.gov Thu Jun 27 20:33:36 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Thu, 27 Jun 2013 13:33:36 -0700 Subject: [cdwg] Maintenance releaase status of 2.5/2.4 In-Reply-To: References: Message-ID: <51CCA1A0.2060907@llnl.gov> Cory, We will have one final discussion on the July 3rd CDWG call. Given that there have been no dissenting opinions on the mailing lists, I suspect that the discussion will be short and announcements will be circulated shortly after. So my powers of prognostication could be on the fritz, but I think it is fairly safe to say "when" at this point. Chris On 06/27/2013 11:25 AM, Cory Spitz wrote: > Chris, > > What do you mean "when we officially announceŠ" I didn't realize that we > had already decided. Do you mean to say, "*if* we officially announceŠ"? > > Thanks, > -Cory > > On 6/27/13 1:13 PM, "Christopher J. Morrone" wrote: > >> Bryan, >> >> We certainly have consensus among the small number of organizations that >> bothered to reply. This will be on the Agenda for next Wednesday's call. >> >> When we officially announce that 2.5 will be a long term maintenance >> release, the we will explain that the maintenance period for 2.4 has >> been shortened dramatically. No longer should folks expect that 2.4 is >> a branch that will be supported for years. Instead its maintenance >> window might be only as long as it takes to get 2.5.0 released. But we >> haven't discussed the exact date to advertise as the cut off. >> >> Chris >> >> On 06/27/2013 08:01 AM, Bryan Cote wrote: >>> Hello, >>> >>> Did we get consensus on whether 2.5 will be a maintenance release, and >>> if so, what is the impact on 2.4? >>> >>> ==Bryan >>> >>> >>> *________________________________________________________________________ >>> ______* >>> >>> *Bryan R. Cote **|**Sr. Product Manager * >>> >>> *M 603.557.3568**|**P 617.722.0090 Ext. 302 **|**F 617.722.6060* >>> >>> *100 North Washington Street **|**Boston, MA 02114* >>> >>> ** >>> >>> cid:image002.jpg at 01CDFB24.4A1E3320** >>> >>> *www.terascala.com * >>> >>> >>> >>> _______________________________________________ >>> cdwg mailing list >>> cdwg at lists.opensfs.org >>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>> >> >> _______________________________________________ >> cdwg mailing list >> cdwg at lists.opensfs.org >> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org > > . > From spitzcor at cray.com Thu Jun 27 21:14:02 2013 From: spitzcor at cray.com (Cory Spitz) Date: Thu, 27 Jun 2013 21:14:02 +0000 Subject: [cdwg] Maintenance releaase status of 2.5/2.4 In-Reply-To: <51CCA1A0.2060907@llnl.gov> Message-ID: Ok, I haven't heard of any objections either. However, I'm more than a bit concerned that the CDWG may recommend that b2_5 become a maintenance branch, but that we aren't prepared to turn out releases from said branch. Peter J. said, "maintenance releases and support is at the discretion of the support providers" when talking about _other_ branches. I'm not sure that he was implying that Intel would substitute 2.4.x for 2.5.x on the roadmap (https://wiki.hpdd.intel.com/display/PUB/Community+Lustre+Roadmap). Since Intel was putting out maintenance releases for the previous maintenance branch, b2_1, I think that they need to be on-board with the suggestion to move to b2_5. Otherwise, the CDWG is going to have to find a way to turn out 2.5.x releases. Thanks, -Cory On 6/27/13 3:33 PM, "Christopher J. Morrone" wrote: >Cory, > >We will have one final discussion on the July 3rd CDWG call. Given that >there have been no dissenting opinions on the mailing lists, I suspect >that the discussion will be short and announcements will be circulated >shortly after. > >So my powers of prognostication could be on the fritz, but I think it is >fairly safe to say "when" at this point. > >Chris > >On 06/27/2013 11:25 AM, Cory Spitz wrote: >> Chris, >> >> What do you mean "when we officially announceŠ" I didn't realize that >>we >> had already decided. Do you mean to say, "*if* we officially >>announceŠ"? >> >> Thanks, >> -Cory >> >> On 6/27/13 1:13 PM, "Christopher J. Morrone" wrote: >> >>> Bryan, >>> >>> We certainly have consensus among the small number of organizations >>>that >>> bothered to reply. This will be on the Agenda for next Wednesday's >>>call. >>> >>> When we officially announce that 2.5 will be a long term maintenance >>> release, the we will explain that the maintenance period for 2.4 has >>> been shortened dramatically. No longer should folks expect that 2.4 is >>> a branch that will be supported for years. Instead its maintenance >>> window might be only as long as it takes to get 2.5.0 released. But we >>> haven't discussed the exact date to advertise as the cut off. >>> >>> Chris >>> >>> On 06/27/2013 08:01 AM, Bryan Cote wrote: >>>> Hello, >>>> >>>> Did we get consensus on whether 2.5 will be a maintenance release, and >>>> if so, what is the impact on 2.4? >>>> >>>> ==Bryan >>>> >>>> >>>> >>>>*______________________________________________________________________ >>>>__ >>>> ______* >>>> >>>> *Bryan R. Cote **|**Sr. Product Manager * >>>> >>>> *M 603.557.3568**|**P 617.722.0090 Ext. 302 **|**F 617.722.6060* >>>> >>>> *100 North Washington Street **|**Boston, MA 02114* >>>> >>>> ** >>>> >>>> cid:image002.jpg at 01CDFB24.4A1E3320** >>>> >>>> *www.terascala.com * >>>> >>>> >>>> >>>> _______________________________________________ >>>> cdwg mailing list >>>> cdwg at lists.opensfs.org >>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>>> >>> >>> _______________________________________________ >>> cdwg mailing list >>> cdwg at lists.opensfs.org >>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >> >> . >> From peter.a.jones at intel.com Thu Jun 27 21:32:58 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Thu, 27 Jun 2013 21:32:58 +0000 Subject: [cdwg] Maintenance releaase status of 2.5/2.4 In-Reply-To: Message-ID: Cory I am sorry if my well-intentioned comments caused concern. I was simply trying to reassure our customers (and potential customers) that they would not be left high and dry if this discussion did not match their requirements. Given that the original plan of action to produce 18 months of 2.4.x maintenance releases was made upon a CDWG recommendation, I do not see how this more recent discussion is any different. Intel HPDD is an active participant in the CDWG and I certainly would not be shy to speak up if something concerned me. We can talk about this more on the call next week or I'd be happy to talk to you before then personally if you cannot wait until then :-) Regards Peter On 6/27/13 2:14 PM, "Cory Spitz" wrote: >Ok, I haven't heard of any objections either. > >However, I'm more than a bit concerned that the CDWG may recommend that >b2_5 become a maintenance branch, but that we aren't prepared to turn out >releases from said branch. > >Peter J. said, "maintenance releases and support is at the discretion of >the support providers" when talking about _other_ branches. I'm not sure >that he was implying that Intel would substitute 2.4.x for 2.5.x on the >roadmap >(https://wiki.hpdd.intel.com/display/PUB/Community+Lustre+Roadmap). Since >Intel was putting out maintenance releases for the previous maintenance >branch, b2_1, I think that they need to be on-board with the suggestion to >move to b2_5. Otherwise, the CDWG is going to have to find a way to turn >out 2.5.x releases. > >Thanks, >-Cory > > > >On 6/27/13 3:33 PM, "Christopher J. Morrone" wrote: > >>Cory, >> >>We will have one final discussion on the July 3rd CDWG call. Given that >>there have been no dissenting opinions on the mailing lists, I suspect >>that the discussion will be short and announcements will be circulated >>shortly after. >> >>So my powers of prognostication could be on the fritz, but I think it is >>fairly safe to say "when" at this point. >> >>Chris >> >>On 06/27/2013 11:25 AM, Cory Spitz wrote: >>> Chris, >>> >>> What do you mean "when we officially announceŠ" I didn't realize that >>>we >>> had already decided. Do you mean to say, "*if* we officially >>>announceŠ"? >>> >>> Thanks, >>> -Cory >>> >>> On 6/27/13 1:13 PM, "Christopher J. Morrone" wrote: >>> >>>> Bryan, >>>> >>>> We certainly have consensus among the small number of organizations >>>>that >>>> bothered to reply. This will be on the Agenda for next Wednesday's >>>>call. >>>> >>>> When we officially announce that 2.5 will be a long term maintenance >>>> release, the we will explain that the maintenance period for 2.4 has >>>> been shortened dramatically. No longer should folks expect that 2.4 >>>>is >>>> a branch that will be supported for years. Instead its maintenance >>>> window might be only as long as it takes to get 2.5.0 released. But >>>>we >>>> haven't discussed the exact date to advertise as the cut off. >>>> >>>> Chris >>>> >>>> On 06/27/2013 08:01 AM, Bryan Cote wrote: >>>>> Hello, >>>>> >>>>> Did we get consensus on whether 2.5 will be a maintenance release, >>>>>and >>>>> if so, what is the impact on 2.4? >>>>> >>>>> ==Bryan >>>>> >>>>> >>>>> >>>>>*_____________________________________________________________________ >>>>>_ >>>>>__ >>>>> ______* >>>>> >>>>> *Bryan R. Cote **|**Sr. Product Manager * >>>>> >>>>> *M 603.557.3568**|**P 617.722.0090 Ext. 302 **|**F 617.722.6060* >>>>> >>>>> *100 North Washington Street **|**Boston, MA 02114* >>>>> >>>>> ** >>>>> >>>>> cid:image002.jpg at 01CDFB24.4A1E3320** >>>>> >>>>> *www.terascala.com * >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdwg mailing list >>>>> cdwg at lists.opensfs.org >>>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>>>> >>>> >>>> _______________________________________________ >>>> cdwg mailing list >>>> cdwg at lists.opensfs.org >>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>> >>> . >>> > >_______________________________________________ >cdwg mailing list >cdwg at lists.opensfs.org >http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org From morrone2 at llnl.gov Thu Jun 27 21:55:48 2013 From: morrone2 at llnl.gov (Christopher J. Morrone) Date: Thu, 27 Jun 2013 14:55:48 -0700 Subject: [cdwg] Maintenance releaase status of 2.5/2.4 In-Reply-To: References: Message-ID: <51CCB4E4.8000306@llnl.gov> Cory, The new official URL for the community roadmap is this: http://lustre.opensfs.org/community-lustre-roadmap/ And, yes, we will absolutely update that roadmap to show 2.5 as the next maintenance branch instead of 2.4. Maybe we'll keep a stubby branch for 2.4 in the picture that shows 2.4.1 and 2.4.2. Unless I completely misunderstood, nothing Peter has said contradicts that plan. He is on board with us advertising 2.5 as the longer term "scheduled maintenance". Peter is just making clear Intel's business plan, which is nice of him to share, and again, does not conflict with the community plan. They are going to support 2.5 for their customers, and they will _also_ support 2.4 for their customers that choose to keep paying for it. Great! LLNL is an Intel customer, and we plan to take them up on that. We are on the path to install 2.4 everywhere soon, and it is not clear to me how quickly we can change our plans to move to 2.5. But we are working on adapting our plans to align with the community and go to 2.5 at the earliest reasonable date. If you are not an Intel customer, then their support of 2.4 for their customers doesn't particularly apply to you. No worries. The important thing is that Intel is agreeing with the plan to advertise regularly scheduled maintenance releases for the 2.5 branch along with the community. Chris On 06/27/2013 02:14 PM, Cory Spitz wrote: > Ok, I haven't heard of any objections either. > > However, I'm more than a bit concerned that the CDWG may recommend that > b2_5 become a maintenance branch, but that we aren't prepared to turn out > releases from said branch. > > Peter J. said, "maintenance releases and support is at the discretion of > the support providers" when talking about _other_ branches. I'm not sure > that he was implying that Intel would substitute 2.4.x for 2.5.x on the > roadmap > (https://wiki.hpdd.intel.com/display/PUB/Community+Lustre+Roadmap). Since > Intel was putting out maintenance releases for the previous maintenance > branch, b2_1, I think that they need to be on-board with the suggestion to > move to b2_5. Otherwise, the CDWG is going to have to find a way to turn > out 2.5.x releases. > > Thanks, > -Cory > > > > On 6/27/13 3:33 PM, "Christopher J. Morrone" wrote: > >> Cory, >> >> We will have one final discussion on the July 3rd CDWG call. Given that >> there have been no dissenting opinions on the mailing lists, I suspect >> that the discussion will be short and announcements will be circulated >> shortly after. >> >> So my powers of prognostication could be on the fritz, but I think it is >> fairly safe to say "when" at this point. >> >> Chris >> >> On 06/27/2013 11:25 AM, Cory Spitz wrote: >>> Chris, >>> >>> What do you mean "when we officially announceŠ" I didn't realize that >>> we >>> had already decided. Do you mean to say, "*if* we officially >>> announceŠ"? >>> >>> Thanks, >>> -Cory >>> >>> On 6/27/13 1:13 PM, "Christopher J. Morrone" wrote: >>> >>>> Bryan, >>>> >>>> We certainly have consensus among the small number of organizations >>>> that >>>> bothered to reply. This will be on the Agenda for next Wednesday's >>>> call. >>>> >>>> When we officially announce that 2.5 will be a long term maintenance >>>> release, the we will explain that the maintenance period for 2.4 has >>>> been shortened dramatically. No longer should folks expect that 2.4 is >>>> a branch that will be supported for years. Instead its maintenance >>>> window might be only as long as it takes to get 2.5.0 released. But we >>>> haven't discussed the exact date to advertise as the cut off. >>>> >>>> Chris >>>> >>>> On 06/27/2013 08:01 AM, Bryan Cote wrote: >>>>> Hello, >>>>> >>>>> Did we get consensus on whether 2.5 will be a maintenance release, and >>>>> if so, what is the impact on 2.4? >>>>> >>>>> ==Bryan >>>>> >>>>> >>>>> >>>>> *______________________________________________________________________ >>>>> __ >>>>> ______* >>>>> >>>>> *Bryan R. Cote **|**Sr. Product Manager * >>>>> >>>>> *M 603.557.3568**|**P 617.722.0090 Ext. 302 **|**F 617.722.6060* >>>>> >>>>> *100 North Washington Street **|**Boston, MA 02114* >>>>> >>>>> ** >>>>> >>>>> cid:image002.jpg at 01CDFB24.4A1E3320** >>>>> >>>>> *www.terascala.com * >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdwg mailing list >>>>> cdwg at lists.opensfs.org >>>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>>>> >>>> >>>> _______________________________________________ >>>> cdwg mailing list >>>> cdwg at lists.opensfs.org >>>> http://lists.opensfs.org/listinfo.cgi/cdwg-opensfs.org >>> >>> . >>> > > . > From peter.a.jones at intel.com Thu Jun 27 22:53:35 2013 From: peter.a.jones at intel.com (Jones, Peter A) Date: Thu, 27 Jun 2013 22:53:35 +0000 Subject: [cdwg] Lustre 2.1.6 released Message-ID: Hi there I am pleased to announce that Lustre 2.1.6 has been declared GA and is available for download at http://downloads.whamcloud.com/public/lustre/latest-maintenance-release/ Release Highlights -support for RHEL6.4 (LU-3461) -addresses a bug whereby duplicate filenames in the same directory could be created (LU-2901) -removes a bug that could result in data corruption if cp(coreutils) uses FIEMAP to obtain data holes in shared file (LU-3219) Changelog details available at https://wiki.hpdd.intel.com/display/PUB/Changelog+2.1 Please log any issues found at https://jira.hpdd.intel.com Regards Peter From oleg.drokin at intel.com Fri Jun 28 19:14:55 2013 From: oleg.drokin at intel.com (Drokin, Oleg) Date: Fri, 28 Jun 2013 19:14:55 +0000 Subject: [cdwg] Large API change landed, please check your pending patches! Message-ID: <236D1F55-6908-405B-AE40-FC3FD267CA72@intel.com> Hello! I just landed a large EMC patche that converted a bunch of CFS_ primitives into standard kernel way of doing things (see below). If your patches have any of those, please rebase proactively now. Thanks. CFS_PAGE_SIZE, CFS_PAGE_SHIFT, cfs_num_physpages, cfs_copy_from_user, cfs_copy_to_user, cfs_page_address, cfs_kmap/cfs_kunmap, cfs_get_page, cfs_page_count, cfs_page_index, cfs_page_pin, cfs_page_unpin, cfs_memory_pressure_get/set/clr, CFS_NUM_CACHEPAGES, CFS_ALLOC_XXX flags, cfs_alloc/free, cfs_alloc/free_large, cfs_alloc/free_page, CFS_DECL_MMSPACE, CFS_MMSPACE_OPEN, CFS_MMSPACE_CLOSE, CFS_SLAB_XXX flags, cfs_shrinker_t, cfs_set/remove_shrinker, CFS_DEFAULT_SEEKS, cfs_mem_cache_t, cfs_mem_cache_alloc/free/create/destroy, cfs_mem_is_in_cache There are some more coming (reviews 4775 4777 4778 4779) but they are not as big. It's still worth seeing if your patches conflict with those too as I hope to land those somewhat fast (reviews permitting). Bye, Oleg From andreas.dilger at intel.com Fri Jun 28 21:59:44 2013 From: andreas.dilger at intel.com (Dilger, Andreas) Date: Fri, 28 Jun 2013 21:59:44 +0000 Subject: [cdwg] Large API change landed, please check your pending patches! In-Reply-To: <236D1F55-6908-405B-AE40-FC3FD267CA72@intel.com> Message-ID: On 2013/28/06 1:14 PM, "Drokin, Oleg" wrote: >Hello! > > I just landed a large EMC patche that converted a bunch of CFS_ >primitives into standard kernel way of doing things (see below). > If your patches have any of those, please rebase proactively now. > > Thanks. > >CFS_PAGE_SIZE, CFS_PAGE_SHIFT, cfs_num_physpages, >cfs_copy_from_user, cfs_copy_to_user, cfs_page_address, >cfs_kmap/cfs_kunmap, cfs_get_page, cfs_page_count, >cfs_page_index, cfs_page_pin, cfs_page_unpin, >cfs_memory_pressure_get/set/clr, CFS_NUM_CACHEPAGES, >CFS_ALLOC_XXX flags, cfs_alloc/free, cfs_alloc/free_large, >cfs_alloc/free_page, CFS_DECL_MMSPACE, CFS_MMSPACE_OPEN, >CFS_MMSPACE_CLOSE, CFS_SLAB_XXX flags, cfs_shrinker_t, >cfs_set/remove_shrinker, CFS_DEFAULT_SEEKS, cfs_mem_cache_t, >cfs_mem_cache_alloc/free/create/destroy, cfs_mem_is_in_cache Note that there is a sed script contrib/scripts/libcfs_cleanup.sed that will handle this cleanup automatically for any symbols that have already been converted. It can be run on the current branch with the following commands: find libcfs lnet lustre -name "*.[ch]" | grep -v gnilnd | xargs sed -i "" -f contrib/scripts/libcfs_cleanup.sed Any resulting changes can be merged into your top patch with "git commit --amend -a". This assumes that the affected lines are in the topmost patch in your branch, otherwise it needs to be run after every patch while doing "git rebase -i" and "edit" for every patch, otherwise the earlier patches will not be able to build. I've also submitted http://review.whamcloud.com/6824 to add a "libcfs_cleanup" target in the top-level makefile to run the sed script as above, but it isn't landed yet. > There are some more coming (reviews 4775 4777 4778 4779) but they are >not as big. It's still worth seeing if your patches conflict with those >too as I hope to land those somewhat fast (reviews permitting). The .sed script above will be updated to handle the changes in those patches as they are landed, so the same process can be used to update your patches regardless of where we are in the patch landings. Cheers, Andreas -- Andreas Dilger Lustre Software Architect Intel High Performance Data Division