From: "Cédric Lemarchand" <cedric.lemarchand@ixblue.com>
To: xfs@oss.sgi.com
Subject: Any way to slow down fragmentation ?
Date: Tue, 13 Oct 2015 23:54:37 +0200 [thread overview]
Message-ID: <561D7D9D.4030409@ixblue.com> (raw)
I think I actually have very bad fragmentation values, which
unfortunately involve performances drop by an order of magnitude of
3x/4x. A defrag is actually running, but it's really really slow, to the
point that I will need to constantly defrag the partition, which is not
optimal. There are approximatively 500Go written sequentially every day,
and almost 10/12T random writes every week due to backup files rotations.
The partition has been formated with default options, over LVM (one
VG/one LV).
Here are somes questions :
- is there mkfs.xfs or mounting options that could reduce the
fragmentation over the time ?
- the backup software writes use blocks size of ~4MB, as the previous
question, any options to optimize differents layers (LVM & XFS) ? The
underlaying FS could handle 1MB block size, should I set this value for
XFS too ? do I need to play with "su" and "sw" as stated in the FAQ ?
I admit that there are so many options that I am a bit lost.
Thanks,
Cédric
--
Some informations : VM running Debian Jessie, underlaying storage is
software raid (ZFS).
df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/VG2-LV1 53685000192 40921853928 12763146264 77% /vrepo1
xfs_db -r /dev/VG2/LV1 -c frag
actual 4222, ideal 137, fragmentation factor 96.76%
xfs_info /dev/VG2/LV1
meta-data=/dev/mapper/VG2-LV1 isize=256 agcount=50,
agsize=268435455 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=13421771776, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
ls -lh
total 26T
-rw-rw-rw- 1 root root 20M Oct 13 23:45 SG DAILY BACKUP.vbm
-rw-r--r-- 1 root root 550G Sep 20 09:08 SG DAILY
BACKUP2015-09-04T200116.vrb
-rw-r--r-- 1 root root 363G Oct 12 00:25 SG DAILY
BACKUP2015-09-07T200129.vrb
-rw-r--r-- 1 root root 156G Sep 12 22:40 SG DAILY
BACKUP2015-09-08T200100.vrb
-rw-r--r-- 1 root root 777G Oct 12 00:20 SG DAILY
BACKUP2015-09-09T200100.vrb
-rw-r--r-- 1 root root 472G Sep 19 09:11 SG DAILY
BACKUP2015-09-10T200113.vrb
-rw-r--r-- 1 root root 617G Sep 19 17:15 SG DAILY
BACKUP2015-09-11T200105.vrb
-rw-r--r-- 1 root root 484G Sep 20 01:14 SG DAILY
BACKUP2015-09-14T200056.vrb
-rw-r--r-- 1 root root 454G Sep 20 15:45 SG DAILY
BACKUP2015-09-15T200119.vrb
-rw-r--r-- 1 root root 374G Sep 20 15:48 SG DAILY
BACKUP2015-09-16T200101.vrb
-rw-r--r-- 1 root root 465G Sep 26 22:50 SG DAILY
BACKUP2015-09-17T200105.vrb
-rw-r--r-- 1 root root 626G Sep 27 08:43 SG DAILY
BACKUP2015-09-18T200110.vrb
-rw-r--r-- 1 root root 533G Sep 27 17:25 SG DAILY
BACKUP2015-09-21T200101.vrb
-rw-r--r-- 1 root root 459G Sep 28 02:36 SG DAILY
BACKUP2015-09-22T200059.vrb
-rw-r--r-- 1 root root 460G Sep 28 11:32 SG DAILY
BACKUP2015-09-23T200111.vrb
-rw-r--r-- 1 root root 516G Oct 12 00:27 SG DAILY
BACKUP2015-09-24T200058.vrb
-rw-r--r-- 1 root root 593G Oct 3 20:05 SG DAILY
BACKUP2015-09-25T200104.vrb
-rw-r--r-- 1 root root 482G Oct 12 00:20 SG DAILY
BACKUP2015-09-28T200108.vrb
-rw-r--r-- 1 root root 466G Oct 12 00:26 SG DAILY
BACKUP2015-09-29T200115.vrb
-rw-r--r-- 1 root root 481G Oct 4 23:41 SG DAILY
BACKUP2015-09-30T200109.vrb
-rw-r--r-- 1 root root 548G Oct 12 00:26 SG DAILY
BACKUP2015-10-01T200115.vrb
-rw-r--r-- 1 root root 703G Oct 11 07:59 SG DAILY
BACKUP2015-10-02T200055.vrb
-rw-r--r-- 1 root root 409G Oct 11 04:05 SG DAILY
BACKUP2015-10-05T200106.vrb
-rw-r--r-- 1 root root 384G Oct 11 10:14 SG DAILY
BACKUP2015-10-06T200059.vrb
-rw-r--r-- 1 root root 335G Oct 11 19:49 SG DAILY
BACKUP2015-10-07T104621.vrb
-rw-r--r-- 1 root root 552G Oct 12 00:27 SG DAILY
BACKUP2015-10-07T200123.vrb
-rw-r--r-- 1 root root 90G Oct 12 00:27 SG DAILY
BACKUP2015-10-08T200113.vrb
-rw-r--r-- 1 root root 13T Oct 12 00:27 SG DAILY
BACKUP2015-10-09T200112.vbk
-rw-r--r-- 1 root root 620G Oct 13 20:01 SG DAILY
BACKUP2015-10-12T200108.vib
-rw-r--r-- 1 root root 424G Oct 13 23:46 SG DAILY
BACKUP2015-10-13T200136.vib
pvdisplay /dev/sdc
--- Physical volume ---
PV Name /dev/sdc
VG Name VG2
PV Size 50.00 TiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 13107199
Free PE 0
Allocated PE 13107199
PV UUID nkbLG0-fUNx-StT7-htil-UksF-GC7i-amDIA9
vgdisplay VG2
--- Volume group ---
VG Name VG2
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 12
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 50.00 TiB
PE Size 4.00 MiB
Total PE 13107199
Alloc PE / Size 13107199 / 50.00 TiB
Free PE / Size 0 / 0
VG UUID sjZjgR-M58f-Shrg-jxKu-TwBq-qL3X-BMXYEn
lvdisplay /dev/VG2/LV1
--- Logical volume ---
LV Path /dev/VG2/LV1
LV Name LV1
VG Name VG2
LV UUID rElcn9-cmsH-K3P5-nKOB-GcV0-fDf9-gozdgT
LV Write Access read/write
LV Creation host, time SG-VREPO1.ixblue.corp, 2015-08-09 10:40:53 +0200
LV Status available
# open 2
LV Size 50.00 TiB
Current LE 13107199
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2015-10-13 21:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 21:54 Cédric Lemarchand [this message]
2015-10-13 22:04 ` Any way to slow down fragmentation ? Eric Sandeen
2015-10-14 18:29 ` Cédric Lemarchand
2015-10-14 18:36 ` Eric Sandeen
2015-10-14 21:34 ` 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=561D7D9D.4030409@ixblue.com \
--to=cedric.lemarchand@ixblue.com \
--cc=xfs@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.