Re: [lustre-discuss] Slow release of inodes on OST

On 2/6/20 6:58 AM, Andreas Dilger wrote: > On Feb 4, 2020, at 07:23, Åke Sandgren <mailto:ake.sandg...@hpc2n.umu.se>> wrote: >> >> When I create a large number of files on an OST and then remove them, >> the used inode count on the OST decreases very slo

Re: [lustre-discuss] Slow release of inodes on OST

On 2/6/20 6:58 AM, Andreas Dilger wrote: > On Feb 4, 2020, at 07:23, Åke Sandgren <mailto:ake.sandg...@hpc2n.umu.se>> wrote: >> >> When I create a large number of files on an OST and then remove them, >> the used inode count on the OST decreases very slo

Re: [lustre-discuss] LUSTRE - Installation on DEBIAN 10.x ????

We're running 2.13.0 server on Ubuntu Bionic 18.04 with 4.15 kernel in our test setup. Has been working without any real problems for a couple of weeks. But it is a small test setup so... For clients we have 2.10.7 from DDN on our production Ubuntu Xenial systems (with HWE kernel so 4.15) On

Re: [lustre-discuss] Slow mount on clients

Which then of course means that if the MDS HA has done a failover it will be slow to mount until it's back in its usual place... Used to happen to us very often when the server side was somewhat unstable. On 2/4/20 8:55 AM, Moreno Diego (ID SIS) wrote: > Not sure if it's your case but the order

Re: [lustre-discuss] Slow release of inodes on OST

. So is there any other tunable I can tweak on either OSS or MDS side? On 2/6/20 6:58 AM, Andreas Dilger wrote: > On Feb 4, 2020, at 07:23, Åke Sandgren <mailto:ake.sandg...@hpc2n.umu.se>> wrote: >> >> When I create a large number of files on an OST and then remove them,

Re: [lustre-discuss] Slow release of inodes on OST

or something? > > >> On Feb 7, 2020, at 02:34, Åke Sandgren > <mailto:ake.sandg...@hpc2n.umu.se>> wrote: >> >> Loocking at the osp.*.sync* values i see >> osp.rsos-OST-osc-MDT.sync_changes=14174002 >> osp.rsos-OST-osc-MDT.sync_in_fl

Re: [lustre-discuss] rsync not appropriate for lustre

I think this might be of some interest https://github.com/hpc/mpifileutils On 1/23/20 4:33 PM, Bernd Melchers wrote: > Hi All, > we are copying large data sets within our lustre filesystem and between > lustre and an external nfs server. In both cases the performance is > unexpected low and the

Re: [lustre-discuss] Slow release of inodes on OST

Forgot to mention that I'm running 2.13.0 from git on the servers. On 2/4/20 3:23 PM, Åke Sandgren wrote: > Hi! > > When I create a large number of files on an OST and then remove them, > the used inode count on the OST decreases very slowly, it takes several > hours for i

[lustre-discuss] Speed of deleting small files on OST vs DoM

Hi! Is there a good reason why deleting lots of small files (io500 test md_easy/hard_delete) with the files on OSTs are up to two times faster then when using DoM with the whole file(s) on the MDT? Using server/client 2.13.0 DoM up to 64k, test files < 4k I can see that the actual data deletion

[lustre-discuss] Lustre server build on Ubuntu

Hi! I'm looking at building the server part on Ubuntu. I can see that there are patches for ldiskfs on Ubuntu18 so someone has clearly done some work here. What are the pre-requisites for doing this? Or even better, does anyone have a working recipy? -- Ake Sandgren, HPC2N, Umea University,

Re: [lustre-discuss] project quotas

The manual has good examples. Chap. 25.2 Enabling Disk Quotas for instance. On 1/7/20 9:07 PM, Peeples, Heath wrote: > I am needing to set up project quotas, but am having a difficult time > finding documentation/examples of how to do this.  Could someone point > me to a good source of

Re: [lustre-discuss] OST -> MDT migration and MDT -> OST migration

On 4/15/21 5:12 AM, Andreas Dilger via lustre-discuss wrote: > On Apr 14, 2021, at 18:42, Bill Anderson via lustre-discuss > > wrote: >> >> >>    Hi All, >> >>    I'm trying to figure out how to migrate files stored on an OST to >> an MDT (that's using 

Re: [lustre-discuss] Jobstats Support with Singularity Container

On 12/14/21 11:29 AM, Andreas Dilger via lustre-discuss wrote: > The JobID is provided by the clients, the servers don't really care how > it was generated. It just has to be <= 32 chars (or is that < 32) -- Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden Internet:

Re: [lustre-discuss] IPoIB best practises

On 1/17/22 2:36 AM, Angelos Ching via lustre-discuss wrote: > Hi Eli, > > Yes & no; part of my info is a bit rusty because I carried them from > version around 2.10. MR is now turned on by default. > > But you'll need to have an IP setup on each IPoIB interface, and for all > ib0 & all ib1

[lustre-discuss] Problems pushing update to patch

Hi! I've probably messed up somehow but I can't see how. When doing git push I'm getting this: === skalman [lustre-release-whamcloud]$ git push review HEAD:refs/for/master ak...@review.whamcloud.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure

Re: [lustre-discuss] Avoiding system cache when using ssd pfl extent

On 5/20/22 09:53, Andreas Dilger via lustre-discuss wrote: To elaborate a bit on Patrick's answer, there is no mechanism to do this on the *client*, because the performance difference between client RAM and server storage is still fairly significant, especially if the application is doing

[lustre-discuss] Misplaced position for two glibc checks

Hi! The tests for LC_GLIBC_SUPPORT_FHANDLES and LC_GLIBC_SUPPORT_COPY_FILE_RANGE must be in the "core" set of configure tests, i.e. in the === AC_DEFUN([LC_CONFIGURE], [ AC_MSG_NOTICE([Lustre core checks === section. The reason for that is that they are required for the client/server utils

[lustre-discuss] Small bug in 2.14 debian/rules

Hi! In 2.14.0 debian/rules there is a comment that breaks a commands \-line continuation causing exported env vars to be dropped. Simple fix is (configure-stamp rule): === diff --git a/debian/rules b/debian/rules index df80c077ba..14b1892fbf 100755 --- a/debian/rules +++ b/debian/rules @@

Re: [lustre-discuss] Small bug in 2.14 debian/rules

Sorry, meant master not 2.14, and it's commit a5084c2f2ec On 6/2/22 10:33, Åke Sandgren wrote: Hi! In 2.14.0 debian/rules there is a comment that breaks a commands \-line continuation causing exported env vars to be dropped. Simple fix is (configure-stamp rule): === diff --git a/debian

Re: [lustre-discuss] Small bug in 2.14 debian/rules

No I didn't, forgot to. Sebastien handled it though. On 6/3/22 00:16, Peter Jones wrote: Ake Have you opened a JIRA ticket about this? Peter On 2022-06-02, 2:01 AM, "lustre-discuss on behalf of Åke Sandgren" wrote: Sorry, meant master not 2.14, and it's commit a5084c2f2ec

Re: [lustre-discuss] need info regarding TCP ports for lustre

On 6/14/22 00:51, Andreas Dilger via lustre-discuss wrote: *Most* of the port 988 connections will be client->server, but occasionally if there is a network problem and the client connection is dropped, then server->client connections may be initiated to cancel a lock or similar.  If this

[lustre-discuss] Question regarding LAD'22 talk on tuning

Hi! I'd like to get in contact with the people behind the "Tuning Lustre in a LNet routed environment" talk at LAD'22 We have some questions for them... -- Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden Internet: a...@hpc2n.umu.se Mobile: +46 70 7716134 Fax: +46 90-580 14 WWW:

[lustre-discuss] Problem pushing PR to review

Hi! I'm currently getting Received disconnect from 138.197.209.17 port 29418:2: Too many authentication failures: 7 Disconnected from 138.197.209.17 port 29418 fatal: Could not read from remote repository. when trying to push a PR for review for LU-16819 It's been a while but my ssh keys is

Re: [lustre-discuss] Problem pushing PR to review

This worked when done from another machine, so ignore. From: lustre-discuss on behalf of Åke Sandgren Sent: Thursday, May 11, 2023 9:19 To: lustre-discuss@lists.lustre.org Subject: [lustre-discuss] Problem pushing PR to review Hi! I'm currently

Re: [lustre-discuss] Build lustre on ubuntu 22.04

Have you looked at the instructions here, https://wiki.whamcloud.com/pages/viewpage.action?pageId=63968116 From: lustre-discuss on behalf of Yao Weng via lustre-discuss Sent: Thursday, February 8, 2024 20:21 To: lustre-discuss@lists.lustre.org Subject:

Re: [lustre-discuss] Problems pushing update to patch

Apparently RSA keys are no longer accepted. Updated key and now it works. From: Åke Sandgren Sent: Thursday, November 9, 2023 8:37 To: Kira Duwe via lustre-discuss Subject: Problems pushing update to patch Hi! I've probably messed up somehow but I can't