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.<div>
<br></div><div>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. <div>
<br></div><div>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.</div>
<div><br><br><div class="gmail_quote">2012/3/15 <span dir="ltr"><<a href="mailto:lustre-discuss-request@lists.lustre.org">lustre-discuss-request@lists.lustre.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
---------- Forwarded message ----------<br>From: Andreas Dilger <<a href="mailto:adilger@whamcloud.com">adilger@whamcloud.com</a>><br>To: <a href="mailto:twg@lists.opensfs.org">twg@lists.opensfs.org</a><br>Cc: wc-discuss <<a href="mailto:wc-discuss@whamcloud.com">wc-discuss@whamcloud.com</a>>, lustre-discuss discuss <<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.org</a>>, Lustre Devel <<a href="mailto:lustre-devel@lists.lustre.org">lustre-devel@lists.lustre.org</a>><br>
Date: Wed, 14 Mar 2012 18:31:29 -0600<br>Subject: [Lustre-discuss] Lustre and cross-platform portability<br>Whamcloud and EMC are jointly investigating how to be able to contribute the Lustre client code into the upstream Linux kernel.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
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. :-)<br>
<br>
Cheers, Andreas<br>
--<br>
Andreas Dilger Whamcloud, Inc.<br>
Principal Lustre Engineer <a href="http://www.whamcloud.com/" target="_blank">http://www.whamcloud.com/</a><br>
<br>
<br>
<br>
<br>
<br>
<br><br></blockquote></div>
</div></div>