From: Wang Yugui <wangyugui@e16-tech.com>
To: Wang Yugui <wangyugui@e16-tech.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: dbench throughput(sync, reflink=0|1) on xfs over hardware throughput
Date: Thu, 15 Oct 2020 06:45:36 +0800 [thread overview]
Message-ID: <20201015064535.35D8.409509F4@e16-tech.com> (raw)
In-Reply-To: <20201014124138.7A0E.409509F4@e16-tech.com>
Hi,
Thanks a lot fo Dave Chinner,
The 'Throughput' of dbench include not only 'write', but also include
'read' in dbench too.
And 'max_latency' include not only 'write', but also include others too.
1)dbench result example1
WriteX 365460 4.474 2279.808
...
Throughput 385.697 MB/sec (sync open) 32 clients 32 procs max_latency=2279.818 ms
2)dbench result example2
WriteX 741543 3.521 16.380
...
Throughput 779.972 MB/sec (sync open) 48 clients 48 procs max_latency=11.246 ms
for ext4, with more clients(32->80), the Throughput of ext4 is over
6Gb/s too.
Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2020/10/15
> Hi,
>
> For xfs sync performance optimization, there is an option 'osyncisdsync'
> which is removed in 4.0(man xfs)
>
> the xfs sync performance optimization in linux 5.4.70/5.9.0 is beyond
> 'osyncisdsync'? When multiple write(sync) at the same time, just some of
> them are guaranteed?
>
> Or deduplication(based on reflink=1) help the sync write?
> and 'mkfs.xfs -m reflink=0' failed to disable it?
>
> iotop show that 'Actual DISK WRITE:' is NOT over hardware throughput.
>
> Best Regards
> Wang Yugui (wangyugui@e16-tech.com)
> 2020/10/14
>
> > Hi,
> >
> > #any reply, please Cc: wangyugui@e16-tech.com
> >
> > dbench throughput(sync, reflink=0|1) on xfs over hardware
> > throughput(6Gb/s=750MB/s).
> >
> > Is this a bug of xfs sync? or some feature of performance optimization?
> >
> > we test mkfs.xfs -m reflink=0|1, crc=0|1, still over hardware
> > throughput(6Gb/s=750MB/s).
> >
> > Disk: TOSHIBA PX05SMQ040
> > This is a 12Gb/s SAS SSD disk, but connect to 6Gb/s SAS HBA,
> > so it works with 6Gb/s.
> >
> > dbench -s -t 60 -D /xfs 32
> > #Throughput 884.406 MB/sec (sync open)
> >
> >
> > dbench -s -t 60 -D /xfs 1
> > #Throughput 149.172 MB/sec (sync open)
> >
> > we test the same disk with ext4 filesystem,
> > the throughput is very close to, but less than the hardware limit.
> >
> > dbench -s -t 60 -D /ext4 32
> > #Throughput 740.95 MB/sec (sync open)
> >
> > dbench -s -t 60 -D /ext4 1
> > #Throughput 124.67 MB/sec (sync open)
> >
> > linux kernel: 5.4.70, 5.9.0
> >
> > Best Regards
> > Wang Yugui (wangyugui@e16-tech.com)
> > 2020/10/13
> >
>
prev parent reply other threads:[~2020-10-14 22:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-13 15:56 dbench throughput(sync, reflink=0|1) on xfs over hardware throughput Wang Yugui
2020-10-14 4:41 ` Wang Yugui
2020-10-14 22:45 ` Wang Yugui [this message]
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=20201015064535.35D8.409509F4@e16-tech.com \
--to=wangyugui@e16-tech.com \
--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 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.