>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 what Colin was going to tell me, and I see
And
>Which version?
Whoops, can you believe I forgot that? It's 2.1.2.
--Ken
___
Lustre-discuss mailing list
Lustre-discuss@lists.lustre.org
http://lists.lustre.org/mailman/listinfo/lustre-discuss
I tried to move my MDS from one filesystem on the same machine to another,
using the procedure outlined in the Lustre manuals (I didn't use dd, since
the underlying disks weren't the same size and also I did not think
it was required).
Specifically, I used rsync to copy the files, and also used ge
>That's good to know kernel-ib comes with the lustre stock install.
>
>What about the rest of the OFED tools? I mean things like ibdiagnet,
>ibstatus, etc? (I will look at the contents of the other rpms and see
>what I can learn)
I think Jeff missed a few steps. If you want the _server-side_ pa
>When I was reading source codes of ldlm, the term "AST" puzzled me. I think
>it means callback, but what is its full name?
Asynchronous software trap. If it makes you feel any better, I had to
ask as well :-/ I was told the term dates back from VMS.
Hm, some quick Googling suggests that it may
>When you refer to ia64, are you referring to the itanium systems?
I'm referring to systems where "uname -p" returns "ia64". Is that
itanium? No idea.
--Ken
___
Lustre-discuss mailing list
Lustre-discuss@lists.lustre.org
http://lists.lustre.org/mail
>I am not finding where it says explicitly that a lustre client running
>1.8 will successfully be able to read and write to a set of lustre
>servers running lustre 2.1. are there any known issues?
I forget where that was written down; I can report that it works fine.
WITH THE EXCEPTION of ia64 1.8
>Also fuse client will able to run on any OS have a FUSE porting that is
>any BSD, OpenSolaris, MacOS, in additional to the windows. That is
>easy way to maintain a single client for many OS.
It is, unfortunately, not quite that simple.
I can't claim to be a FUSE expert, but I've been paying att
>Ken, my apologies for this misstatement. I guess that my faulty memory
>is to blame for the fact that I didn't recall the MacOS code was made
>publicly available for download.
No problem. Back when I gave the talk at LUG the source wasn't available
yet due to issues here, but we got that worked
>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
>According to this FAQ:
>http://groups.google.com/support/bin/answer.py?answer=46438&topic=9257
>
>There's no need for a Google account to join a public Google Group via
>email. But sending an email to wc-discuss+subscr...@googlegroups.com
>and wc-discuss-subscr...@googlegroups.com both ended up wi
>we're struggling mightily to get ubuntu clients working in native IB
>mode against centos lustre/IB servers.
>
>since we've never had a working native IB client, we have no basis in
>our assumption that the speed increase should be tremendous & thus
>justify our struggle.
It really depends on a t
>Doing a manual modprobe on lustre also fails:
>> # modprobe lustre
>> WARNING: Error inserting osc
>> (/lib/modules/2.6.18-194.3.1.el5_lustre.1.8.4/updates/kernel/fs/lustre/osc.ko):
>>
The core problem is Lustre is compiled using the wrong symbol versions
for the OFed you've actually got in th
>Ken, the OSTs need to track the ownership of objects for quota. The more
>stripes there are on a file, the more RPCs that need to be sent, which is why
>we don't recommend wide striping unless there is a reason for it (bandwidth,
>size, etc).
Fair enough; I always forget about quota accounting,
So I guess there are some things I _still_ don't understand about Lustre
metadata handling. Specifically, what metadata gets stored on OSTs and
why.
What brings this all up is that a) we have users who have lots of files
and b) we recently are doing through some reorganization that requires
chang
>Anybody had any experience using an IB based storage
>target as an OST?
We do that.
>Apart from the obvious issue of separating the IB SAN(SRP/SER)
>storage traffic from the Lustre traffic are there any issues?
We don't actually separate the IB traffic from the Lustre traffic; in
our cases they
>I have a report from a user that is is getting EINTR when a SIGALRM goes
>off on his write(). It isn't unexpected to get SIGALRM because he
>called the alarm, but he also has SA_RESTART set. I can't remember
>whose responsibility it is to restart the call, syscall or whereever,
>but it seems
>I don't understand why you don't just fix your application to handle a
>perfectly valid and expected condition (that it's currently not
>handling) instead of wasting time trying to find the cause of the
>expected condition. Even if you find it, it's likely not a bug and not
>something that can/wi
>As for your questions :
>- I have to mention that I always had had this issue, and this is why
>I've upgraded from 1.8.4 to 1.8.5, hoping this would solve it.
Ah, okay, I misunderstood that; my apologies.
>- I will try to have that SA_RESTART flag set in the app... if I can
>find where the signa
>OK, the app is used to deal with standard disks, that is why it is not
>handling the EINTR signal propoerly.
I think you're misunderstanding what a "signal" is in the Unix sense.
EINTR isn't a signal; it's a return code from the write() system call
that says, "Hey, you got a signal in the middle
>But my mount command is failing and that's the issue:
>mount -t lustre 192.168.0.2@tcp0:/temp /lustre
>mount.lustre: mount 192.168.0.2@tcp0:/temp at /lustre failed: No such
>device
>Are the lustre modules loaded?
Right, and every time I've seen the mount command fail like this (with
ENODEV as the
>Dmesg and syslog are clean and has no entries about lustre client.
... are you _sure_? Even /var/log/messages?
I ask because this sure seems like the Lustre modules are not loaded (you
can check that with the lsmod command). If they aren't loaded, then the
core issue will be buried somewhere i
>Thanks for putting in this effort. I think that others would be
>interested (I am). Perhaps you could share your work at github or post
>to lustre-devel ahead of LUG?
Thanks for the words of encouragement!
My boss has no problem with my work being redistributed, but he's not
really a fan of pu
>FYI, 1.8 and 2.0 used to share the ldiskfs patches (we lost this with the
>transition to git), so the ldiskfs module shipped with 1.8.5 (which supports
>SLES11 SP1) already has most of the patches required for lustre 2.0.0. I
>think it would have been less painful to start from there and to add th
>Yes, that is what Oracle had announced in the roadmap.
>
>SLES servers are still supported on Lustre 1.8.x, but Oracle announced
>plans to not support them with Lustre 2.x. Given the similarities
>between the RHEL6 and SLES11 kernels, I am sure someone could bring SLES
>support back when RHEL6
>Okay, so I ran a depmod and then tried again. I am now running into these
>error messages:
>--
>node205:/etc/modprobe.d # modprobe lustre
>WARNING: Error inserting osc
>(/lib/modules/2.6.32.12-0.7-default/updates/kernel/fs/lustre/osc.ko):
>Input/output error
You should in /var/log/messages or in
>Now I have another problem. After last segfault I can not restart the fsck
>due to MMP.
>[...]
>Also when I try to access filesystem via debugfs it fails:
>
>debugfs -c -R 'ls' /dev/scratch2_ost16vg/ost16lv
>debugfs 1.41.10.sun2 (24-Feb-2010)
>/dev/scratch2_ost16vg/ost16lv: MMP: fsck being run whi
>lustre does get unmounted before NFS filesystem as seen in the log message...
>the problem is due to the fact that LNET is still up when openibd gets
>removed.
Huh, I'm wondering how it ever worked "right" before. Certainly on the systems
I have at 1.8.1.1, I always had to have a Lustre start/s
>Using 'tune2fs -f -E clear-mmp' causes tune2fs to segfault:
Ewww well, not sure what to tell you about that.
>Did you use a newer version of tune2fs/e2fsprogs? Our current version
>is e2fsprogs-1.40.11.sun1-0redhat. Do you know if it's safe to rev up
>versions on e2fsprogs while running
>This gives me an MMP error though:
>[r...@oss-0-25 log]# tune2fs -E clear-mmp /dev/sdd
>tune2fs 1.40.11.sun1 (17-June-2008)
>tune2fs: MMP: appears fsck currently being run on the filesystem while
>trying to open /dev/sdd
>Couldn't find valid filesystem superblock.
Oh, I forgot ... did you try ad
>We recently experienced a power failure (and subsequent UPS failure)
>which caused our Lustre filesystem to shutdown hard. We were able to
>bring it back online but started seeing errors where the OSTs were being
>remounted as read-only. We observed that all of the read-only OSTs were
>repor
>Without size-on-mds, either way would have to query both the mds and
>each OST to get the size info. Not being that familiar with size-on-
>mds, it does seem likely that "du" would still have to query the OST
>for size info, even when "ls -l" does not.
As someone who has spent the past week
>...the build them against your kernel -- unless you mean licensing
>support under FreeBSD?
In terms of licensing ... since Lustre is GPL, I can't see any reason
why there would be any licensing conflict.
All you have to do is download the sources, make the few minor changes
to port Lustre to Fr
>Perhaps other SLES users here can post ideas on how they handle this
>situation. I guess for those using heartbeat, this is a non-issue as
>heartbeat handles the mounting and heartbeat is started after
>networking.
So, as a SLES user, let me offer my $0.02.
_netdev still works in the sense that
Greetings all.
Thanks to the good folks at Oracle (who were kind enough to allow me to
use their public Git repository infrastructure, and did all the hard
work of setting up the repo and educating me on the finer points of
pushing to remote Git repos) I am pleased to announce that the source
code
>Feature will not be enabled until e2fsprogsis updated and 'tune2fs -O
>mmp %{device}' is run.
>Normaly MMP should be automaticly enabled with lustre 1.8.x.
>I also installed the newerst e2fsprogs but the error message is the same.
>The rest works fine.
In the specific case of SLES11, not only do
>Make sure you read and understand the Lustre 2.0 release notes before you
>buy. There seemed to be some specifics in there about using Oracle hardware.
In all fairness ... that only matters if you pay Oracle for support. If
you aren't paying Oracle for support (or have no plans to), then it doe
Greetings all.
I am pleased to announce that I have made available an "early alpha" version
of my port of the Lustre client to MacOS X. By "early alpha", I mean that
it works, for me, and it might work for you. But it might crash your
system. Actually, it will probably almost certainly crash yo
>Why not just use the binary kernel we provide instead of rebuilding your
>own? It's the *exact* same kernel that we used in our QA testing and
>therefore a known quantity.
I have to agree with Brian here ... the best success that we've had is to
either use _everything_ from Sun/Oracle (I'm just
>Yes! I created OSTs and did some testing with plain eth configuration
>first, so this would explain things. How can I tell the MDS that things
>have changed?
You'll have to run tunefs.lustre --writeconf (the Lustre manual
explains this in a bit more detail). I had some vague memory that you
o
>At the moment, it seems that all the traffic between clients-OSS goes
>also through the slow eth connection. Is it possible to force them to
>use faster IB interfaces when communication with each other, and only
>use eth to communicate with the MDS?
Stupid question time: is it possible that y
>Thank you very much for your post, it worked!
So ... what was your problem? Wrong version of OFed loaded? Or Lustre
was compiled using the wrong symbol versions?
--Ken
___
Lustre-discuss mailing list
Lustre-discuss@lists.lustre.org
http://lists.lustr
>I also noticed something in trying to compile lustre. The
>"Module.symvers" file is very much needed but is only created after you do
>"make/make modules" in the /usr/src/linux directory. It does NOT exist
>before then and the lustre installation guide makes it seem
>like this file should exist
>You're right, I had problems with the module symbol versions using
>Lustre 1.8.2 packages available at Sun website, kernel
>2.6.18-164.11.1.el5 (RHEL 5.4) and OFED 1.5. The same problems happens
>when using OFED 1.4.2.
So since this comes up now and then, I've cc'd the list.
So you can Google ar
>I've tried also to get Lustre 1.8.2 working with RHEL5.4 and OFED 1.5
>but I didn't get this trio working. Even with OFED 1.4.2 I had problems
>when modprobing lustre module.
I think you had problems with the module symbol versions, right? Those
are relatively easy to track down, once you know a
> I think the original problem you were referring to is "undefined
>symbol: ext2_attr_index_prefix " ? This is fixed in bug#20830 and
>checked in to the cvs. The fix will be available with release of
>e2fsprogs 1.41.9-sun1.
Actually, I just looked at this bug, and this is not the problem
>As well, you should install the e2fsprogs package for your distro and
>architecture.
As long as we're talking about this ... in the case of SLES 11, you
need to install some extra, hidden RPMs to get e2fsprogs to work (I
found those by accident on downloads.lustre.org after spending a bunch
of ti
I have Lustre 1.8.1 running on a bunch of SLES 11/x86_64 systems. I'm
using the stock binaries from www.sun.com. Everything is fine ... except
that some of the e2fsprogs utilites are unhappy. Specifically, if I try
to run e2fsck, I get:
# e2fsck /dev/sdb
e2fsck: symbol lookup error: e2fsck: und
48 matches
Mail list logo
