On Mon, Jan 25, 2010 at 05:24:32PM -0700, Andreas Dilger wrote:
> I agree it makes sense to have a command to do this. As I write this
> I'm offline, so I can't poke at my test filesystem, but thought that /
> proc/fs/lustre/osc/*/import will contain the OST name and NID(s) to
> which they ar
On 2010-01-25, at 16:32, Christopher J. Morrone wrote:
> Richard Lefebvre wrote:
>> 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 comman
From: Lex
Date: Tue, Jan 26, 2010 at 2:12 PM
Subject: Re: [Lustre-discuss] slow direct_io , slow journal .. in OST log
To: Mark Hahn
Cc: Erik Froese
There was a problem with our raid controller this morning, raid array was
degraded ( I reinstalled the hard drive and its state was *rebuilding*
-- Forwarded message --
From: Lex
Date: Tue, Jan 26, 2010 at 9:05 AM
Subject: Re: [Lustre-discuss] slow direct_io , slow journal .. in OST log
To: Mark Hahn
Cc: Erik Froese
On Tue, Jan 26, 2010 at 12:07 AM, Mark Hahn wrote:
> Sorry Erik if i'm rising such a "bad" question,
On Mon, Jan 25, 2010 at 7:10 PM, Wojciech Turek wrote:
> Try rpm -Uhv e2fsprogs-1.41.6.sun1-0redhat.rhel5.x86_64.rpm
Great! That works. Stupid me; I didn't realize what the messages were
trying to tell me.
Thanks!
--
Rahul
___
Lustre-discuss mailing
Try rpm -Uhv e2fsprogs-1.41.6.sun1-0redhat.rhel5.x86_64.rpm
2010/1/26 Rahul Nabar :
> I was trying to install the e2fsprogs package from the Lustre site but
> it seems it conflicts with what I already have installed via yum on my
> CentOS installation:
>
> rpm -ihv e2fsprogs-1.41.6.sun1-0redhat.rh
I was trying to install the e2fsprogs package from the Lustre site but
it seems it conflicts with what I already have installed via yum on my
CentOS installation:
rpm -ihv e2fsprogs-1.41.6.sun1-0redhat.rhel5.x86_64.rpm
file /lib64/libblkid.so.1.0 from install of
e2fsprogs-1.41.6.sun1-0redhat conf
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 serv
On Mon, 2010-01-25 at 11:38 -0700, Lundgren, Andrew wrote:
> Level 3 requested this feature be developed in 1.6. The after Sun did some
> work for us, the following is the procedure that we have setup for usage.
> IIRC the functionality was enabled in 1.6.7. We have tested it in 1.8.0.
Do yo
On Mon, 2010-01-25 at 15:09 +0100, Johann Lombardi wrote:
>
> Yes, the watchdog timer is updated based on the estimated rpc service
> time (multiplied by a factor which is usually 2).
Ahhh. Great. It would be interesting to know which Lustre release the
poster seeing the stack traces was using
Level 3 requested this feature be developed in 1.6. The after Sun did some
work for us, the following is the procedure that we have setup for usage. IIRC
the functionality was enabled in 1.6.7. We have tested it in 1.8.0.
(We have done it in our development and test lab, but never in producti
Brian J. Murrell wrote:
> On Sun, 2010-01-24 at 22:54 -0700, Andreas Dilger wrote:
>> If they are call traces due to the watchdog timer, then this is somewhat
>> expected for extremely high load.
>
> Andreas,
>
> Do you know, does adaptive timeouts take care of setting the timeout
> appropriatel
Sorry Erik if i'm rising such a "bad" question, could u tell me more about
OST journal device ? I even don't know what it is as well as haven't seen it
before, in the lustre manual.
Best regards
On Mon, Jan 25, 2010 at 10:52 PM, Erik Froese wrote:
> Is each OST journals on its own physical dis
I can't stop I/O to the lustre system as you said because it will make our
service goes down. But instead, i can user hdparm with our backup OST, it
has exactly the same hardware info with the master one. And this is the
result :
* hdparm -t /dev/sdc
/dev/sdc:
Timing buffered disk reads: 1318 M
Is each OST journals on its own physical disk? I've seen those messages when
there isn't enough hardware dedicated to the journal device.
Erik
On Sun, Jan 24, 2010 at 11:43 PM, Aaron Knister wrote:
> I don't necessarily think there's anything wrong with using drbd or running
> it over gigabit eth
On Mon, Jan 25, 2010 at 08:51:59AM -0500, Brian J. Murrell wrote:
> Do you know, does adaptive timeouts take care of setting the timeout
> appropriately on watchdogs?
Yes, the watchdog timer is updated based on the estimated rpc service
time (multiplied by a factor which is usually 2).
Johann
___
On Sun, 2010-01-24 at 22:54 -0700, Andreas Dilger wrote:
>
> If they are call traces due to the watchdog timer, then this is somewhat
> expected for extremely high load.
Andreas,
Do you know, does adaptive timeouts take care of setting the timeout
appropriately on watchdogs?
b.
signature.as
hm, and what this supposed to mean? :/
srv:~# dmesg |grep -i 'Forced cleanup'|head -1
LustreError: 0-0: Forced cleanup waiting for rlfs-MDT-mdc-c3956400
namespace with 1 resources in use, (rc=-110)
srv:~# dmesg |grep -i 'Forced cleanup'|wc -l
101
1.8.1.1 server/client, 32bit, two client s
Hi Andreas,
we have reproduced a test case and analyzed it with 'debugfs' and 'stat'
commands the inconsistencies. As you can see in the attached file we
have noticed two kinds of problem, since we see two different behaviors.
First of all, we have built two different lists with e2scan:
One wi
I've just been tuning a small Lustre installation, with two Ethernet
physical networks and have noticed that the bulk of the network traffic
is not going through the intended network. The two networks are
labelled tcp0 and tcp1, and tcp1 is in principle the best network for
OST traffic, becaus
20 matches
Mail list logo
