On 05/18/2017 05:25 PM, Di Natale, Giuseppe wrote:
> Hi Eli,
>
>
> Thanks for the response! From my understanding, /etc/sysconfig is
> intended to contain files which are sourceable by shell scripts. Below
> is a link to a blog post that does a good job explaining.
>
>
>
That most likely means that Lustre does not support a kernel that old
(the kernel structure does not have those fields yet). It looks like
the kernels from CentOS 6.7 and 6.8 will work:
http://build.lustre.org/downloads/tags/2.9.0/centos/
You'll probably need to either upgrade your version of
On 09/13/2016 07:38 AM, Phill Harvey-Smith wrote:
> On 13/09/2016 14:59, Crowe, Tom wrote:
>> Your mkfs.lustre will look something like this:
>>
>> mkfs.lustre ‹ost --mgsnode=NID_OF_MGS --fsname=FS_NAME
>> --index=DECIMAL_NUM
>> ‹backfstype=zfs --network=NET_TYPE testpool/ost-name-here
>>
>> The
On 08/26/2016 12:48 PM, Oleg Drokin wrote:
> (it's best to be written by third parties anyway since once you work too much
> on some code, you take too many things for granted/think they are obvious,
> and then the end result has gaps that make it hard on the outsiders).
That is an common excuse
On 07/15/2016 12:11 PM, Cory Spitz wrote:
> Chris,
>
> On 7/13/16, 2:00 PM, "lustre-discuss on behalf of Christopher J. Morrone"
> <lustre-discuss-boun...@lists.lustre.org on behalf of morro...@llnl.gov>
> wrote:
>
>> If you put both the client and
The bigger problem tends to be memory management issues in Lustre. If
you put both the client and server code on the same node and do any
serious amount of IO, it has been pretty easy in the past to get that
node to go completely out to lunch thrashing on memory issues. If your
server/client
On 06/29/2016 10:36 AM, Martin Hecht wrote:
> Hello,
>
> I have just seen that you managed to mount with a different kernel, but
> let me come back to this error when building your own rpms for a
> specific kernel.
>
> Independent if you use it or not, I believe on lustre servers you need
> to
n
>
> On Fri, Jun 24, 2016 at 4:15 PM, Christopher J. Morrone
> <morro...@llnl.gov <mailto:morro...@llnl.gov>> wrote:
>
> Yes, it is all a lot harder than it should be at this point. We're
> slowly getting in packaging changes that sho
Yes, it is all a lot harder than it should be at this point. We're
slowly getting in packaging changes that should make it a little easier
in future releases. But fear not, it is doable.
There are other ways, but here is how I would do it with 2.8:
Skip the installation of the lustre-patched
LLNL has always in the past upgraded the servers first.
Chris
On 06/22/2016 09:01 AM, E.S. Rosenberg wrote:
> I always understood the recommendation was to update the clients (and
> LNET Routers) before the servers and not the other way around?
>
>
> On Tue, Jun 21, 2016 at 1:16 AM, Mohr Jr,
This is more of a lustre-discuss topic, so I'm taking my reply there.
Can you describe how you installed lmt? Most likely there is some
problem with the cerebro setup, and the data isn't getting to the node
on which you are running ltop.
There are some instructions here:
I believe that they just forgot to build lnetctl into the recent
packages. lctl is a very old, core lustre command; it is not something
new that is replacing lnetctl.
Chris
On 04/01/2016 05:09 AM, jeevan.patn...@wipro.com wrote:
> Hi,
>
>
>
> I have found out that lnetctl is been replaced
On 03/01/2016 01:44 PM, Drokin, Oleg wrote:
>
> On Mar 1, 2016, at 4:14 PM, Christopher J. Morrone wrote:
>
>> On 03/01/2016 09:18 AM, Alexander I Kulyavtsev wrote:
>>
>>> is tag 2.5.3.90 considered stable?
>>
>> No. Generally speaking you
On 03/01/2016 09:18 AM, Alexander I Kulyavtsev wrote:
> is tag 2.5.3.90 considered stable?
No. Generally speaking you do not want to use anything with number 50
or greater for the fourth number unless you are helping out with testing
during the development process.
2.5.3 was the last official
The first comment in the ticket is from "Gerrit Updater" and includes
the string "Christopher J. Morrone (morro...@llnl.gov) uploaded a new
patch: http://review.whamcloud.com/17536;
If you follow that URL, you will find the patch that I uploaded. All
Lustre community change c
Is your OS CentOS 6.7 then? You _might_ be hitting bug LU-7534, but I'm
not sure how DKMS behaved under CentOS 6.7.
Do the following directories exist on your system?
/var/lib/dkms/spl/0.6.4.2/build
/var/lib/dkms/zfs/0.6.4.2/build
If not, then you need my patch from LU-7534.
Chris
On
On 12/04/2015 10:46 AM, Mohr Jr, Richard Frank (Rick Mohr) wrote:
The balance between features and stability is a complex topic, but it is one
that Lustre developers care about. For a recent thread on this topic, take a
look at:
.
If that doesn't show anything, you probably need to mount your MDT's
backend filesystem as a local filesytem (readonly) and look for where
the space is going.
Chris
On 10/16/2015 10:37 AM, Christopher J. Morrone wrote:
Hi Torsten,
There is no reason to suspect that space usage on the MDT
Hi Torsten,
There is no reason to suspect that space usage on the MDT will be the
same as the average space usage on the OSTs.
Your MDT is storing the metadata about _all_ of the files in your Lustre
filesystem. You can think of this metadata as a whole bunch of
zero-length files with some
If you provide the zpool list -v output it might give us a little
clearer view of what you have going on.
Chris
On 08/19/2015 06:18 AM, Götz Waschk wrote:
Dear Lustre experts,
I have configured two different Lustre instances, both using Lustre
2.5.3, one with ldiskfs on RAID-6 hardware RAID
I could be wrong, but I don't think that the original poster was asking
why the SIZE field of zpool list was wrong, but rather why the AVAIL
space in zfs list was lower than he expected.
I would find it easier to answer the question if I knew his drive count
and drive size.
Chris
On
No, the source for Intel's Enterprise Edition is not available at
lustre.org. They keep the branch and releases for their EE product
private. Yes, they forked the branch for their EE release from
something that can be found at lustre.org, but they will have
considerable change on their EE
What version of Lustre are you using? I don't can't reproduce your
problem on master.
Chris
On 07/15/2015 02:10 PM, Christopher J. Morrone wrote:
You could try seeing if --without-o2ib gets you what you want. It
might not, but at least it is quick to try.
Chris
On 07/15/2015 01:41 PM
You could try seeing if --without-o2ib gets you what you want. It
might not, but at least it is quick to try.
Chris
On 07/15/2015 01:41 PM, Sean Caron wrote:
Hi all,
Sorry for the cross-post from the Intel Lustre list but hoping I might
get more traction here...
Working with my Git pull
Hmmm. There are certainly some puzzling things done in the lustre build
system around O2IB options and debian packaging. Sorry, don't think
I'll be of much help on this one.
chris
On 07/15/2015 02:25 PM, Christopher J. Morrone wrote:
What version of Lustre are you using? I don't can't
I think the major problem is going to be that your MDT image is not
terribly useful without the OSTs that belong to the MDT. The new OSTs
don't contain any of the objects that the MDT references.
Back at old Lustre 2.1 code you won't have any of the lfsck code that
can deal with the MDT to
I do not think that is the case. Mixing OSTs and clients is often bad
as well. It is generally a question of memory contention.
You can get away with mixing clients with any of the server types if
your demands are modest enough. That is why we sometimes say it is OK
for testing. But even
For me, at least, that did not clear up what you meant by records
size. IOR would not have any thing that it sized at 1MB with the
options that you gave as an example.
The only 1MB I can think of in the entire system is that the client may
aggregate 128 of the sequential 8KB IOR writes into
links to category information in the sidebar. I'm guessing that
can either be done manually by a site admin or with a mediawiki
extension of some kind.
Thanks again,
Scott
On 4/28/2015 3:11 PM, Christopher J. Morrone wrote:
On 04/28/2015 11:58 AM, Scott Nolin wrote:
Hello,
With the new
One way is through google's site: search term. If you include this in
the search box:
site:lists.lustre.org/pipermail/lustre-discuss
It will restrict the answers to those found in the lustre-discuss
archive pages.
Chris
On 03/13/2015 09:45 AM, Jerome wrote:
Dear all
Is there a way to
Yes, I am all for more use of http://wiki.opensfs.org. When you make a
page worth pointing to from the sidebar, drop me a note and I can add it.
Chris
On 08/14/2014 09:37 AM, Cory Spitz wrote:
Oops, I meant to copy l...@lists.opensfs.org (not lustre.org).
LWG, see below.
Thanks,
-Cory
On
Odds are that you would be able to do it. How well it would perform,
and how easy it would be to admin are other questions. :)
Unless you have other needs for it to be Lustre, you might consider
Ceph. I believe that Ceph is used quite commonly to serve VM images.
Chris
On 06/10/2014 03:41
Dear Lustre Community,
This is a REMINDER that the 2014 Lustre Survey under way NOW!
Please note that the Survey will complete on Friday, March 14th.
Here is the orginal announcement in case you missed it the first time:
The OpenSFS Community Development Working Group is gathering data from
Dear Lustre Community,
The OpenSFS Community Development Working Group is gathering data from
oranizations using Lustre in order to develop a long-term support
strategy recommendation for Lustre.
We want to ensure that future Lustre releases are well-aligned with the
needs of the Lustre
On 12/17/2013 03:52 PM, Sten Wolf wrote:
I have 2 more questions:
1. Is dual-mgs supported with zfs? My issue seems to be mgs and mdt on
same node, when mgs is configured for 2 nodes
2. Which is recommended? ldiskfs w/ 2x mdt, or zfs w/ single mdt?
I assumed the llnl seqouia implementation
Background
--
The Lustre community has banded together to work on the development of
the Lustre source code. As part of that effort, we regularly discuss
the roadmap for major Lustre releases. We have developed a schedule of
major releases that occur every six months.
We recognize,
Only the _client_ portion of lustre was added to the kernel tree, and
currently it is just in staging. We have been able to build the
lustre client without patches to the kernel for quite some time now,
independent of the work to get the client into the upstream kernel.
On the server side,
On 06/13/2013 05:19 AM, E.S. Rosenberg wrote:
On Thu, Jun 13, 2013 at 3:09 AM, Christopher J. Morrone
morro...@llnl.gov wrote:
Lustre does not manage the individual disks. I sits on top of a
filesystem, either ldiskfs(basically ext4) or zfs (as of Lustre 2.4).
Is ZFS the recommended fs
at 10:22 AM, Christopher J. Morrone
morro...@llnl.gov mailto:morro...@llnl.gov wrote:
On 06/13/2013 05:19 AM, E.S. Rosenberg wrote:
On Thu, Jun 13, 2013 at 3:09 AM, Christopher J. Morrone
morro...@llnl.gov mailto:morro...@llnl.gov wrote:
Lustre does not manage
, Christopher J. Morrone
morro...@llnl.gov mailto:morro...@llnl.gov wrote:
I think you may be confused about what a stripe is in Lustre. If
there are only 2 OST, then you can only stripe a file across 2.
Or maybe I don't understand your terminology. I don't know what you
mean
words, accessing 0 and 4 would take longer time than accessing
0 and 2.
Jaln
On Thu, Jun 13, 2013 at 5:23 PM, Christopher J. Morrone
morro...@llnl.gov mailto:morro...@llnl.gov wrote:
In that case, it is the question part that I do not understand. :)
What is stripe 0,4, why could
On 06/12/2013 04:59 AM, E.S. Rosenberg wrote:
Is lustre.org not being maintained anymore?
Not as far as I can tell.
The Lustre community has moved to using the OpenSFS Lustre portal instead:
http://lustre.opensfs.org
Chris
___
Lustre-discuss
, at 11:16 AM, Christopher J. Morrone morro...@llnl.gov
wrote:
On 06/12/2013 04:59 AM, E.S. Rosenberg wrote:
Is lustre.org not being maintained anymore?
Not as far as I can tell.
The Lustre community has moved to using the OpenSFS Lustre portal instead:
http://lustre.opensfs.org
Lustre does not manage the individual disks. I sits on top of a
filesystem, either ldiskfs(basically ext4) or zfs (as of Lustre 2.4).
You group multiple disks into a single block devices or filesystem using
any of the normal mechanisms: hardware raid, linux mdraid, zfs pools, etc.
On
On 06/04/2013 11:10 AM, Ken Hornstein wrote:
Which version of Lustre is this? File based backup / restore does not work
in 2.x. OI scrub which rebuilds the object index is available from Lustre
2.3 onwards. So file based backup / restore will work from 2.3 onwards.
Well, crud. I guess that's
Mike,
That is going to be very challenging. There are known implementation
problems in the Lustre 2.X client code that are holding back performance
when you have multiple threads trying to write to the same file on the
same lustre client node. See ticket:
What is your comfort level with git and C programming? Because this is
a source code patch that you are talking about. Honestly, you are
almost certainly better off just upgrading to lustre 2.1.3, or better
yet lustre 2.1.4.
If you know git, and are comfortable resolving patch conflicts
On 10/02/2012 01:19 PM, Cory Spitz wrote:
Cray has started looking at testing w/forced memory allocation failures
from the Linux fault injection framework
(http://www.kernel.org/doc/Documentation/fault-injection/fault-injection.txt).
As we make progress we'll open tickets and push patches.
We have never had battery backup on our OSS nodes and we have been
successful in that mode.
Years ago, powering off an OSS or MDS uncleanly was very dangerous. A
lot of work went into fixing ext/ldiskfs, and we have been reasonably
successful at surviving power outages in production for a few
On 07/18/2011 07:47 AM, Kevin Van Maren wrote:
While MPI can achieve 3.2GB/s data rates, I have never seen o2ib lnet
get that high. As I recall,
something ~2.5 is more typical.
I saw ~3GB/s with lnet-selftest on QDR quite recently. One run was
reporting ~3.1GB/s.
Chris
My biggest complaint is that discussion about an issue and its
associated patch(es) is scattered about in multiple locations instead of
located in a single bug like with bugzilla.
Here is a list of things I have had trouble with:
- jira: There is no clue in the jira ticket that the
My seach-fu is failing me.
I seem to recall a discussion about OST mounts being sequentialized,
even if the mount commands are issued in parallel. Perhaps something
about a superblock lock being to blame.
Does any one recall that discussion? Is there a bug open on this? Was
there any
Thats the one. Thanks, Jason!
On 03/16/2011 02:25 PM, Jason Rappleye wrote:
On Mar 16, 2011, at 2:18 PM, Christopher J. Morrone wrote:
My seach-fu is failing me.
I seem to recall a discussion about OST mounts being sequentialized,
even if the mount commands are issued in parallel
You are using IP traffic control, right? So you need to make lustre use
IP over IB instead of native IB.
You need to set up lnet to use the socklnd instead of the o2iblnd.
You'll need to use lnet network names like tcp0 instead of o2ib0.
I don't know what is is you hope to investigate in
On 08/11/2010 01:38 AM, Daniel Kobras wrote:
On Wed, Aug 11, 2010 at 09:53:01AM +0200, Heiko Schröter wrote:
According to lfs find the stripe should be on scia-OST0017_UUID. lfs
gestripe reports to have it on obdidx 23 , which is scia-OST0014 according
to lctl dl. Which one is true ?
lctl
On 07/08/2010 04:51 PM, John Hammond wrote:
How about a network file system waiting for server failover
(especially if it is not automatic)?
That's not indefinite. The FS is waiting for something which will
eventually occur. (Assuming it's is correctly administered).
That IS indefinite.
On 07/05/2010 11:19 PM, Peter Kitchener wrote:
Hi all,
I have been troubleshooting a strange problem that is occurring with our
Lustre setup. Under high loads our developers are complaining that various
processes they run will error out with I/O error.
Our setup is small 1 MDS and 2
Dan wrote:
Hi,
Recently 3 OSTs started showing up as IN when lctl dl is run. nbsp;I cannot
get the to activate and indicate UP, no data is being written to them but we
can read from them.
I've tried lctl conf_param as well as the lctl --device 9 activate method.
nbsp;How else can I
Cliff White wrote:
I don't know what your constraints are, but should note that this sort
of information (number of OSTs) can be obtained rather trivially from
any lustre client via shell prompt, to wit:
# lctl dl |grep OST |wc -l
2
or:
# ls /proc/fs/lustre/osc | grep OST |wc -l
2
IF
melanie gao wrote:
Yes, we're updating lustre-version.ac - you can follow the progress
under bug #22234.
I think we should be able to accommodate your request to add the
additional field you mentioned. Could I ask you to file a bug for this
and cc: me?
Done. For everyone's reference I
I assume that there will be some modifications to
lustre/autoconf/lustre-version.ac and elsewhere to support this?
While you are in there, I'd like to request that you add a field for
third-party folks to add their own version. For instance, we add a
-20chaos tag to our version numbers to
Here we use an init script that does that.
We use it on RHEL based systems, but it shouldn't take much work to
modify it for your needs:
http://github.com/morrone/lustre/raw/1.8.2.0-5chaos/lustre/scripts/lnet
It is also in a patch attached to bug 20165 (/etc/init.d/lnet) along
with heartbeat
Richard Lefebvre wrote:
Hi,
I have been going through the operations manual, but I can't find the
answer of how to find on which OSS each OST are?
Yes, that seems like an oversight to me too. I'd like to see lfs have a
new command to make this lookup easier.
If you have access to the
Mag Gam wrote:
Are there any plans to move away from Bugzilla for issue tracking? I
have been lurking around https://*bugzilla.lustre.org for several
months now and I still find it very hard to use, do others have the
same feeling? or is there a setting or a preferred filter to see all
the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
We are using a home-grown set of init scripts. There is an lnet init
script to bring up the lnet networking, and a lustre init script to
start lustre services.
We tend to be paranoid about the possibility of double mounting a
multi-homed LUNs, so
65 matches
Mail list logo
