Imagine … trying to get something as simple as a quote for Lustre support …

… and not being able to.
Seems most of the folks at Sun/Oracle haven’t heard of Lustre. I had to explain it to them on several calls yesterday. They didn’t understand why someone would want to pay for support of a GPL licensed system …
er …
ah …
mebbe we found some real nice gotchas, and want to get Sun to work on them, and give us a hand in ameliorating them?
I know … too early into the acquisition to really know, but some of the responses have been interesting thus far.
If you know how to get a Lustre support contract out of Sun/Oracle, please, by all means, send me your telephone number. I’d like to shorten the time it takes to walk these trees until we accidentally find the right people.
(I shouldn’t complain, as I am so far behind on my own work in generating quotes … the irony is not lost on me … in our part it is due to a very healthy demand, and an ever expanding pipeline)

7 thoughts on “Imagine … trying to get something as simple as a quote for Lustre support …”

  1. Sounds like a business opportunity for Cray’s custom engineering folks. Let’s see if they capitalize on it before the Ceph client is generalized to work with many servers.

    • @Jason
      Not sure that they want to own Lustre, code or otherwise. Cray might be able to take on the support roles, but I am not sure how viable of a long term business model this would be … Lustre is terribly invasive into the kernel, requiring patches that limit options for distributions and kernels in general. Right now we are dealing with a case where Lustre doesn’t support updated SLES 11 kernels, they run on a modified SLES11 kernel, one that has specific RPC/NFS bugs, and the updated kernel, the one we are trying to support for our customer … they don’t work on.
      Ceph, by nature of it being in the kernel, won’t require anything like this. Its already ported.
      I am not saying Ceph will kill Lustre. I am saying that I think Lustre has many barriers to adoption, of their own creation, and will be competing with code with far fewer barriers to adoption. We know how these ‘contests’ turn out. Unless something drastically changes, the system with the barriers eventually goes away.

  2. Sorry for the late comment, but I am in the same boat and just came across the following info on the Lustre group on LinkedIn: Peter Braam has a company called ClusterStor ( that offers support contracts for Lustre based on OSS count. +1 (again) for open source software.

  3. @Joe the folks I spoke to at SC’09 on the Lustre booth said they were dropping support for SLES and just supporting Red Hat.
    Of course now Oracle have dropped the bombshell that they will only support Lustre on their Red Hat rebuild, which renders that moot.

    • @Chris
      Actually, its even worse than that. I have the Lustre roadmap slides, and have had discussions with a few folks (including Clusterstor).
      Lustre 2.0 and later will not be supported (as in them accepting bug reports/patches) as far as I understand, for anything other than Oracle hardware. This is a concise synopsis of their position, I hope I am representing it correctly.
      Lustre 2.0 will be GPL … BUT … new features may not be GPL or released into the GPL stream. This one is stated almost precisely like this.
      I’ll have a longer post on it soon, but this is basically the situation. Lustre support is being turned off (effectively) to anyone but Oracle hardware purchasers, and (some) new features are not going to be available in the GPL version.
      While Clusterstor has this support as its business, I am not sure how this will work going forward.

  4. It’s not fully clear from the LUG slides, but there are some vaguely hopeful notes in them
    1) They will continue to host “public git source code repository with canonical releases”
    2) They will continue to accept software defect reports from the community and address them.
    3) They will continue to accept community patches submitted ” based on established contributions guidelines” for canonical release branches.
    4) Core filesystem will continue to be GPLv2 (they understand that they can’t role other code into the kernel) *but* (as you point out) there may be other components (user space I presume) which may not be open source.
    I also detect a potential warning shot from BP in their slides called “Hedging Our Filesystem Bet”:

    If you make certification of Lustre 2 configurations too onerous on vendors, we won???t have options ??? Lustre drops off list of options.


    Large LUN support can???t wait. 8/16TB LUNs won???t be practical beyond 2TB drives. Ldiskfs needs to keep up. If ZFS on Solaris is only path forward then we won???t be able to choose other integrators besides Oracle ??? therefore, Lustre will not be on our list of filesystem choices for very long.

Comments are closed.