Cray no longer deploys liblustre. Therefore, we probably take a 'don't care' position in the discussion about the future of liblustre or libcfs.
Thanks, -Cory On 03/16/2012 01:45 AM, Alexey Lyashkov wrote: > If cray don't wan't to use a liblustre single thread client - liblustre is > good start to create a multi platform client. > As i know it's work now on Mac and FreeBSD, as Windows have a FUSE port - > it's should be work in Windows also. > > > On Mar 16, 2012, at 02:53, Nathan Rutman wrote: > >> We had a thought that a FUSE-based client based on liblustre might make >> sense to avoid the NFS/Samba re-export problems (scalability, coherency), at >> the potential price of some performance. You mentioned on the phone this >> morning that someone had already done something like this in the past? If >> we revive this work, presumably we can drop the Mac native client. >> On the other hand, I agree that the baggage is large, and it will take much >> more work to see this through, and without a real champion and/or a real >> community need, I understand the desire to drop it. >> >> On Mar 15, 2012, at 11:38 AM, Andreas Dilger wrote: >> >>> 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
