linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Michael Arndt <Michael.Arndt@berlin.de>
Cc: linux-xfs@vger.kernel.org
Subject: Re: Fwd: xfs remove / unlink extremely slow ?
Date: Wed, 14 Nov 2018 09:45:11 -0500	[thread overview]
Message-ID: <20181114144511.GB19257@bfoster> (raw)
In-Reply-To: <14251045-1CCF-4E35-95F1-F6597FD8FD8C@berlin.de>

On Wed, Nov 14, 2018 at 12:42:49PM +0100, Michael Arndt wrote:
> Hello XFS Gurus,
> 
> Problem: /bin/rm extremely slow on a major xfs (SSD based) HPC Storage
> slow == 90 seconds for unlink of an empty file without any extents
> strace says: time completely used for unlink call
> 
> Question; Is there any issue resolution ?
> 
> Information re XFS Version and OS at end of this Post
> 
> Example of issue:
> 
> 
> [root@atgrzsl3150 DOM_0]# xfs_bmap -a .AN_720.0000122.fl3step_0.lock 
> 
> .AN_720.0000122.fl3step_0.lock: no extents
> [root@atgrzsl3150 DOM_0]# ls -laFtr .AN_720.0000122.fl3step_0.lock 
> 
> -rw-rw-r-- 1 user group 0 Oct 22 14:14 .AN_720.0000122.fl3step_0.lock
> 
> 
> strace -T -tt /bin/rm .AN_720.0000122.fl3step_0.lock 
> 
> 
> 1:41:11.621005 execve("/bin/rm", ["/bin/rm", ".AN_720.0000122.fl3step_0.lock"], [/* 31 vars */]) = 0 <0.000169>11:41:11.621312 brk(NULL)               = 0x6f5000 <0.000023>11:41:11.621378 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4d96017000 <0.000058>
> …….
> 11:41:11.622485 newfstatat(AT_FDCWD, ".AN_720.0000122.fl3step_0.lock", {st_mode=S_IFREG|0664, st_size=0, ...}, AT_SYMLINK_NOFOLLOW) = 0 <0.000009>
> 11:41:11.622522 geteuid()               = 0 <0.000009>
> -> 11:41:11.622546 unlinkat(AT_FDCWD, ".AN_720.0000122.fl3step_0.lock", 0) = 0 <89.612833>
> -> 11:42:41.235428 lseek(0, 0, SEEK_CUR)   = -1 ESPIPE (Illegal seek) <0.000065>
> 11:42:41.235548 close(0)                = 0 <0.000052>
> 11:42:41.235689 close(1)                = 0 <0.000011>
> 11:42:41.235738 close(2)                = 0 <0.000055>
> 11:42:41.235830 exit_group(0)           = ?
> 11:42:41.235941 +++ exited with 0 +++
> 

It might be useful to do something like:

  trace-cmd record -e xfs:* <rm command>

... and either put the resulting trace.dat somewhere where it can be
downloaded or if not too large, run 'trace-cmd report' and copy the text
into a mail (without reformatting it).

Brian

> xfs_info /dev/mapper/vg_calc2-calc2
> meta-data=/dev/mapper/vg_calc2-calc2 isize=512    agcount=50, agsize=268435448 blks
>         =                       sectsz=512   attr=2, projid32bit=1
>         =                       crc=1        finobt=0 spinodes=0
> data     =                       bsize=4096   blocks=13421711360, imaxpct=20
>         =                       sunit=8      swidth=40 blks
> naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
> log      =internal               bsize=4096   blocks=521728, version=2
>         =                       sectsz=512   sunit=8 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> 
> Issue on:
> 
> xfsprogs-4.5.0-18.el7.x86_64
> xfsdump-3.1.7-1.el7.x86_64
> Red Hat Enterprise Linux Server release 7.4 (Maipo)
> df -kh .
> Filesystem                  Size  Used Avail Use% Mounted on
> /dev/mapper/vg_calc2        50T   20T   31T  40% /calc2
> 
> Layers: 
> 
> SSD based commercial Storage exports many small LUN’s -> LUN#s striped via LVM2 for speed, xfs with default opts on top of LVM
> Currently no discard Option for mount and no fstrim manually called
> 
> Mount Options used
> /dev/mapper/vg_calc2-calc2 /calc2 xfs noatime,delaylog,nobarrier,nodiratime,logbsize=256k,logbufs=8 0 0 
> 
> thanks for any tip / hint / question
> Micha
> 

  reply	other threads:[~2018-11-15  0:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3927644F-734A-4A2A-BACB-DE44CBC812EB@berlin.de>
2018-11-14 11:42 ` Fwd: xfs remove / unlink extremely slow ? Michael Arndt
2018-11-14 14:45   ` Brian Foster [this message]
2018-11-15 15:38     ` Brian Foster
2018-11-15 17:07       ` Michael Arndt
2018-11-15 17:07       ` Michael Arndt
2018-11-15 17:35         ` Brian Foster
2018-11-15 22:28       ` Fwd: " Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181114144511.GB19257@bfoster \
    --to=bfoster@redhat.com \
    --cc=Michael.Arndt@berlin.de \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).