similar to: Enable async journals

On Thursday, September 02, 2010, Frank Heckes wrote: > Hi all, > > for some of our OSSes a massive amount of errors like: > > Sep 2 20:28:15 jf61o02 kernel: blk_rq_check_limits: over max size > limit. > > appearing in /var/log/messages (and dmesg). Does anyone have got a clue > how-to get of the root cause? Many thanks in advance. linux/block/blk-core.c int

Hi everyone, we are using custom dfree commands to implement quotas. While these work fine on normal shares, the "dfree command" parameter seems to be ignored in the homes section. Is this correct (and intended)? Best regards Felix IT-Services Telefon 02461 61-9243 E-Mail: f.stolte at fz-juelich.de -------------------------------------------------------------------------------------

Afternoon I upgraded our oss''s from 1.8.3 to 1.8.4 on Saturday (due to https://bugzilla.lustre.org/show_bug.cgi?id=22755) and suffered a great deal of pain. We have 30 oss''s of multiple vintages. The basic difference between them is * md on first 20 nodes * 3ware 9650SE ML12 on last 10 nodes After the upgrade to 1.8.4 we were seeing terrible throughput on the nodes with

Some clients have been removed several weeks ago but are still listed in: ls -l /proc/fs/lustre/obdfilter/*/exports/ This was found after tracing back mystery tcp packets to the OSS. Although this is causing no damage, it raises the question of when former clients will be cleared from the OSS. Is there a way to manually remove these exports from the OSS? -- Regards, David

Hey all, up until 2 weeks ago my samba DC was running just fine, then it began crashing randomly. I was using 4.8.0 before, now upgraded to a self-compiled 4.8.3 with default build parameters on an up-to-date centos 7.5 with disabled SELinux and bind9 as DNS backend with samba_dlz. The log output at log level = 10 is as follows: Jul 17 14:49:20 hostname samba[4998]: [2018/07/17 14:49:20.587655,

Hi, Our lustre environment is: 2.6.9-55.0.9.EL_lustre.1.6.3smp I would like to change recovery timeout from default value 250s to something longer I tried example from manual: set_timeout <secs> Sets the timeout (obd_timeout) for a server to wait before failing recovery. We performed that experiment on our test lustre installation with one OST. storage02 is our OSS [root at

Hi Felix, On 4/18/24 08:33, Stolte, Felix via samba wrote: > Is this a bug or maybe a misconfiguration? In the latter, which parameters could cause this? I guess the nodes end up using different combinations of dev/inode as primary key for the locking.tdb record. Probably because the device numbers differ on the nodes and you didn't fix this known issue with GPFS with the fileid VFS

Dear All, We have a small setup of lustre with 7 OSTs on 8gb FC . We have kept one OST per FC port. We have lustre 2.3 with CentOS 6.3. There are 32 clients which access this over FDR IB. We can achieve more than 1.3GB/s throughput using IOR, without cache. Which is roughly 185MB/s per OST. We wanted to know if this is normal. Should we expect more from 8gb FC port. OSTs are on 8+2 RAID6 .

I''m evaluating lustre. I''m trying what I think is a basic/simple ethernet config. with MDT and OST on the same node. Can someone tell me if the following (~150 second recovery occurring when small 190 GB OST is re-mounted) is expected behavior or if I''m missing something? I thought I would send this and continue with the eval while awaiting a response. I''m using

Greetings-- Packages for Lustre 1.0.2 are now available in the usual place http://www.clusterfs.com/download.html This bug-fix release resolves a number of issues, of which a few are user-visible: - the default debug level is now a more reasonable production value - zero-copy TCP is now enabled by default, if your hardware supports it - you should encounter fewer allocation failures

Greetings-- Packages for Lustre 1.0.2 are now available in the usual place http://www.clusterfs.com/download.html This bug-fix release resolves a number of issues, of which a few are user-visible: - the default debug level is now a more reasonable production value - zero-copy TCP is now enabled by default, if your hardware supports it - you should encounter fewer allocation failures

Hai Felix, It might be handy to show the line your using for dfree. And could you tell us the OS and samba version your using. Last, is this on a member and/or AD-DC ? Greetz, Louis > -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Stolte, Felix via samba > Verzonden: maandag 29 april 2019 9:50 > Aan: samba at

Hi, We run four-node Lustre 2.3, and I needed to both change hardware under MGS/MDS and reassign an OSS ip. Just the same, I added a brand new 10GE network to the system, which was the reason for MDS hardware change. I ran tunefs.lustre --writeconf as per chapter 14.4 in Lustre Manual, and everything mounts fine. Log regeneration apparently works, since it seems to do something, but

Hello, lfs prints different obd(idx) compared to lctl dl. We use single striping. cluster1 tmp # lfs find --obd scia-OST0017_UUID /data/scia/L0/V0.00/20100327/SCI_NL__0PNPDE20100327_193441_000040582088_00071_42209_1158.N1 /data/scia/L0/V0.00/20100327/SCI_NL__0PNPDE20100327_193441_000040582088_00071_42209_1158.N1 cluster1 tmp # lfs getstripe

All, I''ve added a new 2.2 TB OST to my cluster easily enough, but this new disk array is meant to replace several smaller OSTs that I used to have of which were only 120 GB, 500 GB, and 700 GB. Adding an OST is easy, but how do I REMOVE the small OSTs that I no longer want to be part of my cluster? Is there a command to tell luster to move all the file stripes off one of the nodes?

Greetings! I am working with Lustre-2.1.2 on RHEL 6.2. First I configured it using the standard defaults over TCP/IP. Everything worked very nicely usnig a real, static --mgsnode=a.b.c.x value which was the actual IP of the MGS/MDS system1 node. I am now trying to integrate it with Pacemaker-1.1.7. I believe I have most of the set-up completed with a particular exception. The "lctl

Hi, We''re setting up fairly large Lustre 2.1.2 filesystems, each with 18 nodes and 159 resources all in one Corosync/Pacemaker cluster as suggested by our vendor. We''re getting mixed messages on how large of a Corosync/Pacemaker cluster will work well between our vendor an others. 1. Are there Lustre Corosync/Pacemaker clusters out there of this size or larger? 2.

Hello Lustre Experts I am trying to solve a problem with very slow "ls" and other big amount of file operations but good overall read/write rates. We are running a small cluster of 3 OSSs with 9 OSTs, 1MDS (with SSD MDT) and currently two clients. All server nodes are centos 5.2 with lustre 1.8.1 while the clients are centos 5.4 with lustre 1.8.3. All components are networked with DDR

Hi; One of our OSTs filled up. Once we realized this, we executed lctl --device 9 deactivate on our fs''s combo MDS/MGS machine. We saw in the syslog that the OST in question was deactivated: Lustre: setting import ufhpc-OST0008_UUID INACTIVE by administrator request However, ''lfs df'' on the clients does not show that the OST is deactivated there, unless we *also*

This morning I''ve had both my infiniband and tcp lustre clients hiccup. They are evicted from the server presumably as a result of their high load and consequent timeouts. My question is- why don''t the clients re-connect. The infiniband and tcp clients both give the following message when I type "df" - Cannot send after transport endpoint shutdown (-108). I''ve