On 2012-03-15, at 8:22 AM, Tyler Hawes wrote: > Having a native Windows & Mac client is by far our company's #1 most > important feature for the future. We have been seriously considering how we > could help make this happen, including putting funds and/or developers toward > the cause.
Tyler, thanks for your feedback. While at Oracle, there was serious effort put toward having a Windows Native Client. Unfortunately, this died along with other Oracle Lustre development projects, and the proprietary code has been sitting unused inside Oracle since then. Similarly, the MacOS native client project started a couple of years ago, but as yet none of the code has been released. While some work was done for a Solaris server, I don't see much hope in that making progress at all. In both cases, I would be supportive of these efforts if there was a likelihood of them bearing fruit any time in the future, but so far I haven't seen any progress in that direction. If Oracle could somehow release the WNC code and/or NRL can overcome the government roadblocks in their path for releasing the MacOS client (MLC?), it would definitely change the direction of my thinking. As it stands now, we have portability code for Windows/Mac without any ability to even build the code, let alone test it, so it is just a burden for Linux. If there was real value being derived from that code (e.g. actual users), then it might be an acceptable burden. > I know we're in the minority on this, but I believe it's because we are not > using Lustre for HPC. We use it for post-production of TV/film. There are a > few others companies in our industry who have started doing this as well. My > point is that, while Lustre currently is focused on the HPC crowd who seem > not to care about Windows/Mac, Lustre's maturity is giving it the potential > to grow into other uses besides HPC. I wouldn't call them general use, but > other high-performance uses. In our industry, where there are a lot of > Windows & Mac workstations that we want to connect to the Lustre storage, the > Linux-only client is a major obstacle to that. I'm sure there are other > industries that would benefit from this. Yes, the TV/film industry was one of the prime motivators for WNC. There have always been a small number of users from this market, and growth in this industry (and others) is definitely welcomed. > If the community wants to keep Lustre strictly HPC focused and discourage > other industries from joining in, then abandoning the bridge (albeit the > half-built bridge that it is) to Linux/Windows is a good way to do that. If, > on the other hand, there is a desire to get some other industries involved, > perhaps with more resources and contribution coming from them, then I think > it's important to build on the work that has been done. In that regard, > upstream Linux kernel inclusion seems like a very low priority to me. I think even for upstream kernel submission, if it were clear that the layering in Lustre was for a valid purpose (i.e. existing Mac/Win clients) then it might be accepted. As it stands now, we can't honestly make that argument to the kernel maintainers. > 2012/3/15 <[email protected]> > ---------- Forwarded message ---------- > From: Andreas Dilger <[email protected]> > To: [email protected] > Cc: wc-discuss <[email protected]>, lustre-discuss discuss > <[email protected]>, Lustre Devel > <[email protected]> > Date: Wed, 14 Mar 2012 18:31:29 -0600 > Subject: [Lustre-discuss] Lustre and cross-platform portability > Whamcloud and EMC are jointly investigating how to be able to contribute the > Lustre client code into the upstream Linux kernel. > > As a prerequisite to this, EMC is working to clean up the Lustre client code > to better match the kernel coding style, and one of the anticipated major > obstacles to upstream kernel submission is the heavy use of code abstraction > via libcfs for portability to other operating systems (most notably MacOS and > WinNT, but also for liblustre, and potentially *BSD). > > I have no information that the WinNT project will ever be released by Oracle, > and as yet there has not been any code released from the MacOS port, so the > libcfs portability layer is potentially exacting a high cost in code > maintenance and complexity (CLIO being a prime example) for no apparent > benefit. Similarly, the liblustre client needs a portability layer for > userspace, and suffers from the same apparent lack of interest or users. > > I'd like to get some feedback from the Lustre community about removing the > libcfs abstraction entirely, or possibly restructuring it to look like the > Linux kernel API, and having the other platforms code against it as a Linux > portability layer, like ZFS on Linux uses the Solaris Portability Layer (SPL) > to avoid changing the core ZFS code. A related topic is whether it would be > better to replace all cfs_* functions with standard Linux kernel functions > en-masse, or migrate away from cfs_* functions slowly? > > Also, we're planning on deprecating the liblustre client code, due to lack of > interest/usage. The current code is in disrepair, and we've been keeping it > around for years without any benefit, and while I was one of the strongest > advocates for keeping it in our back pocket in case of future needs, I don't > see that materializing in the future. > > The liblustre code would be left in the tree for now, in case someone from > the community is interested to get it working and maintain it, and it may be > updated on a best effort basis. If nobody steps forward to do this work, the > liblustre code would be deleted from the development branch in a year or so. > > > Unfortunately, after starting this thread, I may not be able to reply to > questions in a timely manner due to vacation. I look forward to a thread > that concludes with unanimous agreement from all parties. :-) > > Cheers, Andreas > -- > Andreas Dilger Whamcloud, Inc. > Principal Lustre Engineer http://www.whamcloud.com/ > > > > > > > Cheers, Andreas -- Andreas Dilger Whamcloud, Inc. Principal Lustre Engineer http://www.whamcloud.com/ _______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
