xfs
[Top] [All Lists]

RE: mkfs.xfs -n size=65536

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: RE: mkfs.xfs -n size=65536
From: "Al Lau (alau2)" <alau2@xxxxxxxxx>
Date: Fri, 6 Nov 2015 02:06:42 +0000
Accept-language: en-US
Cc: "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@xxxxxxxxx; l=2579; q=dns/txt; s=iport; t=1446775605; x=1447985205; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RC6GgwgeCzK77D+160/7w7wtJGbWwmh+aQYm8fhWo4U=; b=R9QknTpX67IgLrCyVErfvo5TbnhLJJ8YKaLIIYhJ769+dqXIF33UGiFe pqgVqSlbTZf6EesSBLtjvU5+zUWCn7aO72Y0AuWP2FnO3OmHtWlFMedbz vzm6rephN/7Niyu96dUsNd4QMhbSOFGOab9ylZhbKnTVts0AxQ+kyE4sK 0=;
In-reply-to: <20151013082548.GH31326@dastard>
References: <0F279340237AA148AD7E3C6A70561A5E01266BE7@xxxxxxxxxxxxxxxxxxxxx> <20151013002308.GI27164@dastard> <8a1b26a3b869448e805485c529c447a4@xxxxxxxxxxxxxxxxxxxxx> <20151013033304.GL27164@dastard> <c88efb6bc4ad49779e965a7a67b2df57@xxxxxxxxxxxxxxxxxxxxx> <20151013043016.GE31326@dastard> <b391cb17b6714a479150f9681380e102@xxxxxxxxxxxxxxxxxxxxx> <20151013082548.GH31326@dastard>
Thread-index: AdEC1680Gy4Y381SQNu4wXlh8fvUqwCn49kAAAhmBND///HgAIAAThiA///B5ACAACU6gIAAHJQA/9sHP2A=
Thread-topic: mkfs.xfs -n size=65536
We run the systemtap script in the background.  The kmem_alloc message appeared 
in the /var/log/messages.  The call stack is captured by the systemtap is 
follow.

 0xffffffffa02a0030 : xfs_err+0x0/0x90 [xfs]
 0xffffffffa02a853d : kmem_alloc+0xbd/0xf0 [xfs]
 0xffffffffa02eeb6e : xfs_log_commit_cil+0x39e/0x4c0 [xfs]
 0xffffffffa02a7d3c : xfs_trans_commit+0x11c/0x240 [xfs]
 0xffffffffa02dd353 : xfs_remove+0x343/0x380 [xfs]
 0xffffffffa029d93a : xfs_vn_unlink+0x5a/0xc0 [xfs]
 0xffffffff811bde51
 0xffffffff811be056 (inexact)
 0xffffffff811b166e (inexact)
 0xffffffff810823cc (inexact)
 0xffffffff811c11b6 (inexact)
 0xffffffff815f3219 (inexact)

Nov  5 18:13:21 csx-ceph1-003 kernel: XFS: possible memory allocation deadlock 
in kmem_alloc (mode:0x8250)

#! /usr/bin/env stap

probe module("xfs").function("xfs_err").call
{
  print_backtrace();
}

# nohup stap -o /var/systemtap/kmem_alloc_bt.out backtrace.stp &

Redhat support case is https://access.redhat.com/support/cases/#/case/01500239

Thanks,
-Al
-----Original Message-----
From: Dave Chinner [mailto:david@xxxxxxxxxxxxx] 
Sent: Tuesday, October 13, 2015 1:26 AM
To: Al Lau (alau2)
Cc: xfs@xxxxxxxxxxx
Subject: Re: mkfs.xfs -n size=65536

On Tue, Oct 13, 2015 at 07:28:48AM +0000, Al Lau (alau2) wrote:
> Are the xfs_db and filefrag the utilities to use to determine file 
> fragmentation?
> 
> # df -k /var/kmem_alloc
> Filesystem      1K-blocks       Used Available Use% Mounted on
> /dev/sdf1      3905109820 3359385616 545724204  87% /var/kmem_alloc
> # xfs_db -r -c frag /dev/sdf1
> actual 438970, ideal 388168, fragmentation factor 11.57%

http://xfs.org/index.php/XFS_FAQ#Q:_The_xfs_db_.22frag.22_command_says_I.27m_over_50.25._Is_that_bad.3F

> # ls -l fragmented
> -rw-r--r--. 1 root root 3360239878657 Oct 13 07:25 fragmented # 
> filefrag fragmented
> fragmented: 385533 extents found

That's a lot of extents, but for a 3TB sparse file that is being written in 
random 4k blocks, that's expected and there's little you can do about it. 
Preallocation of the file or use of extent size hints will reduce physical 
fragmentation, but you only want to use those if the file will eventually 
become non-sparse and sequential read IO performance is required...

i.e. the definition of "fragmented" really depends on the application, IO 
patterns and whether the current physical layout is acheiving the desired 
performance attributes of the file in question....

Cheers,

Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>
  • RE: mkfs.xfs -n size=65536, Al Lau (alau2) <=