[Lustre-discuss] Lustre and cross-platform portability

Tyler Hawes tyler at litpost.com
Thu Mar 15 07:22:42 PDT 2012


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.

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.

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.


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/
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20120315/9287d0ff/attachment.htm>


More information about the lustre-discuss mailing list