[Lustre-discuss] [wc-discuss] Re: Lustre and cross-platform portability

[Nathan Rutman]

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 <lustre-discuss-request at lists.lustre.org>
>> ---------- Forwarded message ----------
>> From: Andreas Dilger <adilger at whamcloud.com>
>> To: twg at lists.opensfs.org
>> Cc: wc-discuss <wc-discuss at whamcloud.com>, lustre-discuss discuss <lustre-discuss at lists.lustre.org>, Lustre Devel <lustre-devel at lists.lustre.org>
>> 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/
> 
> 
> 
>