Re: Bad Metadata performances for XFS?

Re: Bad Metadata performances for XFS?

[Dave Chinner]

[xfs@oss.sgi.com is where you'll find the XFS developers]

On Mon, Jul 04, 2016 at 05:32:40AM +0000, Wang Shilong wrote:
> Hello Guys,
> 
>       I happened run some benchmarks for XFS, and found some intresting to share here:
> Kernel version:
> [root@localhost shm]# uname -r
> 4.7.0-rc5+
> 
> [root@localhost shm]# cat /proc/cpuinfo  | grep Intel
> vendor_id	: GenuineIntel
> model name	: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
> 
> dd 16GB to /dev/shm/data to use memory backend storage to benchmark metadata performaces.
> 
> Benchmark tool is mdtest, you can download it from 
> https://sourceforge.net/projects/mdtest/
> 
> Steps to run benchmark
> #mkfs.xfs /dev/shm/data
> #mount /dev/shm/data /mnt/test
> #mdtest -d /mnt/test -n 2000000
> 
> 1 tasks, 2000000 files/directories
> 
> SUMMARY: (of 1 iterations)
>    Operation                      Max            Min           Mean        Std Dev
>    ---------                      ---            ---           ----        -------
>    Directory creation:      24724.717      24724.717      24724.717          0.000
>    Directory stat    :    1156009.290    1156009.290    1156009.290          0.000
>    Directory removal :     103496.353     103496.353     103496.353          0.000
>    File creation     :      23094.444      23094.444      23094.444          0.000
>    File stat         :    1158704.969    1158704.969    1158704.969          0.000
>    File read         :     752731.595     752731.595     752731.595          0.000
>    File removal      :     105481.766     105481.766     105481.766          0.000
>    Tree creation     :       2229.827       2229.827       2229.827          0.000
>    Tree removal      :          1.275          1.275          1.275          0.000
> 
> -- finished at 07/04/2016 12:54:26 --
> 
> IOPS for file creation is only 2.3W, however compare to Ext4 with same testing.
>   Operation                      Max            Min           Mean        Std Dev
>    ---------                      ---            ---           ----        -------
>    Directory creation:      65875.462      65875.462      65875.462          0.000
>    Directory stat    :    1060115.356    1060115.356    1060115.356          0.000
>    Directory removal :     109955.606     109955.606     109955.606          0.000
>    File creation     :     114898.425     114898.425     114898.425          0.000
>    File stat         :    1046223.044    1046223.044    1046223.044          0.000
>    File read         :     699663.339     699663.339     699663.339          0.000
>    File removal      :     152320.304     152320.304     152320.304          0.000
>    Tree creation     :      19065.018      19065.018      19065.018          0.000
>    Tree removal      :          1.269          1.269          1.269          0.000
> 
> IOPS of file creation is more than 11W!!!
> 
> I understand Ext4 use Hash index tree and XFS use B+ tree for directroy, so i test Btrfs
> for this case.
>   ---------                      ---            ---           ----        -------
>    Directory creation:      99312.866      99312.866      99312.866          0.000
>    Directory stat    :    1116205.199    1116205.199    1116205.199          0.000
>    Directory removal :      66441.011      66441.011      66441.011          0.000
>    File creation     :      91282.930      91282.930      91282.930          0.000
>    File stat         :    1117636.580    1117636.580    1117636.580          0.000
>    File read         :     754964.332     754964.332     754964.332          0.000
>    File removal      :      69708.657      69708.657      69708.657          0.000
>    Tree creation     :      29746.837      29746.837      29746.837          0.000
>    Tree removal      :          1.289          1.289          1.289          0.000
> 
> Even Btrfs, it got about 9W....
> 
> Hmm..Maybe this is because too many files under single directory?(200W won't be too much i guess)
> I reduce number of files for XFS to 50W.
> 1 tasks, 500000 files/directories
> 
> SUMMARY: (of 1 iterations)
>    Operation                      Max            Min           Mean        Std Dev
>    ---------                      ---            ---           ----        -------
>    Directory creation:      53021.632      53021.632      53021.632          0.000
>    Directory stat    :    1187581.191    1187581.191    1187581.191          0.000
>    Directory removal :     108112.695     108112.695     108112.695          0.000
>    File creation     :      51654.911      51654.911      51654.911          0.000
>    File stat         :    1180447.310    1180447.310    1180447.310          0.000
>    File read         :     755391.001     755391.001     755391.001          0.000
>    File removal      :     108415.353     108415.353     108415.353          0.000
>    Tree creation     :       2129.088       2129.088       2129.088          0.000
>    Tree removal      :          5.272          5.272          5.272          0.000
> 
> -- finished at 07/04/2016 12:59:17 --
> 
> So performances go up from 2.3W to 5.1W, but still very slow compared to others...
> 
> 
> PS: mkfs options for Btrfs is: mkfs.btrfs -m single -d single -f
>        mkfs options for XFS is: mkfs.xfs -f
>        mkfs options for Ext4 is: mkfs.ext4 -i 2048(to generate enough inodes for testing)
> 
> Best Regards,
> Shilong
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bad Metadata performances for XFS?

[Dave Chinner]

On Tue, Jul 05, 2016 at 08:52:26AM +1000, Dave Chinner wrote:
> [xfs@oss.sgi.com is where you'll find the XFS developers]
> 
> On Mon, Jul 04, 2016 at 05:32:40AM +0000, Wang Shilong wrote:
> > Hello Guys,
> > 
> >       I happened run some benchmarks for XFS, and found some intresting to share here:
> > Kernel version:
> > [root@localhost shm]# uname -r
> > 4.7.0-rc5+
> > 
> > [root@localhost shm]# cat /proc/cpuinfo  | grep Intel
> > vendor_id	: GenuineIntel
> > model name	: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

What's the rest of the hardware in the machine?

> > dd 16GB to /dev/shm/data to use memory backend storage to benchmark metadata performaces.

I've never seen anyone create a ramdisk like that before.
What's the backing device type? i.e. what block device driver does
this use?

> > Benchmark tool is mdtest, you can download it from 
> > https://sourceforge.net/projects/mdtest/

What version? The sourceforge version, of the github fork that the
sourceforge page points to? Or the forked branch of recent
development in the github fork?

> > Steps to run benchmark
> > #mkfs.xfs /dev/shm/data

Output of this command so we can recreate the same filesystem
structure?

> > #mount /dev/shm/data /mnt/test
> > #mdtest -d /mnt/test -n 2000000
> > 
> > 1 tasks, 2000000 files/directories
> > 
> > SUMMARY: (of 1 iterations)
> >    Operation                      Max            Min           Mean        Std Dev
> >    ---------                      ---            ---           ----        -------
> >    Directory creation:      24724.717      24724.717      24724.717          0.000
> >    Directory stat    :    1156009.290    1156009.290    1156009.290          0.000
> >    Directory removal :     103496.353     103496.353     103496.353          0.000
> >    File creation     :      23094.444      23094.444      23094.444          0.000
> >    File stat         :    1158704.969    1158704.969    1158704.969          0.000
> >    File read         :     752731.595     752731.595     752731.595          0.000
> >    File removal      :     105481.766     105481.766     105481.766          0.000
> >    Tree creation     :       2229.827       2229.827       2229.827          0.000
> >    Tree removal      :          1.275          1.275          1.275          0.000
> > 
> > -- finished at 07/04/2016 12:54:26 --

A table of numbers with no units or explanation as to what they
mean. Let me guess - I have to read the benchmark source code to
understand what the numbers mean?

> > IOPS for file creation is only 2.3W, however compare to Ext4 with same testing.

Ummm - what unit of measurement is "W"? Watts?

Please, when presenting benchmark results to ask for help with
analysis, be *extremely specific* about what you running and what
the results mean. It's no different from reporting a bug from this
perspective:

http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F

That said, this is a single threaded benchmark. It's well
known that XFS uses more CPU per metadata operation than either ext4
or btrfs, so it won't be any surprise that they are faster than XFS
on this particular test. We've known this for many years now -
perhaps you should watch/read this presentation I did more than 4
years ago now:

http://xfs.org/index.php/File:Xfs-scalability-lca2012.pdf
http://www.youtube.com/watch?v=FegjLbCnoBw

IOWs: Being CPU bound at 25,000 file creates/s is in line with
what I'd expect on XFS for a single threaded, single directory
create over 2 million directory entries with the default 4k
directory block size....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

RE: Bad Metadata performances for XFS?

[Wang Shilong]

Hello Dave Chinner,

________________________________________
From: Dave Chinner [david@fromorbit.com]
Sent: Tuesday, July 05, 2016 8:18
To: Wang Shilong
Cc: linux-xfs@vger.kernel.org; xfs@oss.sgi.com
Subject: Re: Bad Metadata performances for XFS?

On Tue, Jul 05, 2016 at 08:52:26AM +1000, Dave Chinner wrote:
> [xfs@oss.sgi.com is where you'll find the XFS developers]
>
> On Mon, Jul 04, 2016 at 05:32:40AM +0000, Wang Shilong wrote:
> > Hello Guys,
> >
> >       I happened run some benchmarks for XFS, and found some intresting to share here:
> > Kernel version:
> > [root@localhost shm]# uname -r
> > 4.7.0-rc5+
> >
> > [root@localhost shm]# cat /proc/cpuinfo  | grep Intel
> > vendor_id   : GenuineIntel
> > model name  : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

What's the rest of the hardware in the machine?
[root@localhost ~]# cat /proc/meminfo 
MemTotal:       32823104 kB
MemFree:        29981320 kB
MemAvailable:   31672712 kB
Buffers:            6176 kB
Cached:          1241192 kB
SwapCached:            0 kB
Active:           938332 kB
Inactive:         692420 kB
Active(anon):     384576 kB
Inactive(anon):   111320 kB
Active(file):     553756 kB
Inactive(file):   581100 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:             11324 kB
Writeback:             0 kB
AnonPages:        383496 kB
Mapped:           186516 kB
Shmem:            112496 kB
Slab:            1059544 kB
SReclaimable:    1020764 kB
SUnreclaim:        38780 kB
KernelStack:        6896 kB
PageTables:        22160 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    16411552 kB
Committed_AS:    2382640 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      194868 kB
DirectMap2M:     3874816 kB
DirectMap1G:    30408704 kB

[root@localhost ~]# dmidecode -t memory
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.

Handle 0x0041, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 32 GB
	Error Information Handle: Not Provided
	Number Of Devices: 4

Handle 0x0042, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x0041
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8192 MB
	Form Factor: DIMM
	Set: None
	Locator: ChannelA-DIMM0
	Bank Locator: BANK 0
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1600 MHz
	Manufacturer: Kingston
	Serial Number: 692A784E
	Asset Tag: 9876543210
	Part Number: KHX1600C10D3/8GX  
	Rank: 2
	Configured Clock Speed: 1333 MHz
	Minimum Voltage: 1.5 V
	Maximum Voltage: 1.5 V
	Configured Voltage: 1.5 V

Handle 0x0044, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x0041
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8192 MB
	Form Factor: DIMM
	Set: None
	Locator: ChannelA-DIMM1
	Bank Locator: BANK 1
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1600 MHz
	Manufacturer: Kingston
	Serial Number: 672A954E
	Asset Tag: 9876543210
	Part Number: KHX1600C10D3/8GX  
	Rank: 2
	Configured Clock Speed: 1333 MHz
	Minimum Voltage: 1.5 V
	Maximum Voltage: 1.5 V
	Configured Voltage: 1.5 V

Handle 0x0046, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x0041
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8192 MB
	Form Factor: DIMM
	Set: None
	Locator: ChannelB-DIMM0
	Bank Locator: BANK 2
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1600 MHz
	Manufacturer: Kingston
	Serial Number: 712AE08D
	Asset Tag: 9876543210
	Part Number: KHX1600C10D3/8GX  
	Rank: 2
	Configured Clock Speed: 1333 MHz
	Minimum Voltage: 1.5 V
	Maximum Voltage: 1.5 V
	Configured Voltage: 1.5 V

Handle 0x0048, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x0041
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8192 MB
	Form Factor: DIMM
	Set: None
	Locator: ChannelB-DIMM1
	Bank Locator: BANK 3
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1600 MHz
	Manufacturer: Kingston
	Serial Number: 6A2A144E
	Asset Tag: 9876543210
	Part Number: KHX1600C10D3/8GX  
	Rank: 2
	Configured Clock Speed: 1333 MHz
	Minimum Voltage: 1.5 V
	Maximum Voltage: 1.5 V
	Configured Voltage: 1.5 V



> > dd 16GB to /dev/shm/data to use memory backend storage to benchmark metadata performaces.

I've never seen anyone create a ramdisk like that before.
What's the backing device type? i.e. what block device driver does
this use?

I guess you mean loop device here? It is common file and setup
as loop0 device here.

> > Benchmark tool is mdtest, you can download it from
> > https://sourceforge.net/projects/mdtest/

What version? The sourceforge version, of the github fork that the
sourceforge page points to? Or the forked branch of recent
development in the github fork?

I don't think sourceforge version or github version make some
differences here, you could use any of them.(I used Souceforge version)


> > Steps to run benchmark
> > #mkfs.xfs /dev/shm/data

Output of this command so we can recreate the same filesystem
structure?

[root@localhost shm]# mkfs.xfs data
meta-data=data                   isize=512    agcount=4, agsize=1025710 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0
data     =                       bsize=4096   blocks=4102840, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


> > #mount /dev/shm/data /mnt/test
> > #mdtest -d /mnt/test -n 2000000
> >
> > 1 tasks, 2000000 files/directories
> >
> > SUMMARY: (of 1 iterations)
> >    Operation                      Max            Min           Mean        Std Dev
> >    ---------                      ---            ---           ----        -------
> >    Directory creation:      24724.717      24724.717      24724.717          0.000
> >    Directory stat    :    1156009.290    1156009.290    1156009.290          0.000
> >    Directory removal :     103496.353     103496.353     103496.353          0.000
> >    File creation     :      23094.444      23094.444      23094.444          0.000
> >    File stat         :    1158704.969    1158704.969    1158704.969          0.000
> >    File read         :     752731.595     752731.595     752731.595          0.000
> >    File removal      :     105481.766     105481.766     105481.766          0.000
> >    Tree creation     :       2229.827       2229.827       2229.827          0.000
> >    Tree removal      :          1.275          1.275          1.275          0.000
> >
> > -- finished at 07/04/2016 12:54:26 --

A table of numbers with no units or explanation as to what they
mean. Let me guess - I have to read the benchmark source code to
understand what the numbers mean?

You could look File Creation, Units mean number of files create per seconds.
(Here it is 23094.444)


> > IOPS for file creation is only 2.3W, however compare to Ext4 with same testing.

Ummm - what unit of measurement is "W"? Watts?

Sorry, same as above..


Please, when presenting benchmark results to ask for help with
analysis, be *extremely specific* about what you running and what
the results mean. It's no different from reporting a bug from this
perspective:

http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F

That said, this is a single threaded benchmark. It's well
known that XFS uses more CPU per metadata operation than either ext4
or btrfs, so it won't be any surprise that they are faster than XFS
on this particular test. We've known this for many years now -
perhaps you should watch/read this presentation I did more than 4
years ago now:

http://xfs.org/index.php/File:Xfs-scalability-lca2012.pdf
http://www.youtube.com/watch?v=FegjLbCnoBw

IOWs: Being CPU bound at 25,000 file creates/s is in line with
what I'd expect on XFS for a single threaded, single directory
create over 2 million directory entries with the default 4k
directory block size....
----------

I understand that this is single thread Limit, but I guess there are some
other Limit here, because even single thread creating 50W files speed
is twice than 200W files.

Thanks,
Shilong

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bad Metadata performances for XFS?

[Dave Chinner]

[Please fix you mail program to correctly quote replies - I've done
it manually here so i could work out what your wrote ]

On Tue, Jul 05, 2016 at 01:43:33AM +0000, Wang Shilong wrote:
> From: Dave Chinner [david@fromorbit.com]
> On Tue, Jul 05, 2016 at 08:52:26AM +1000, Dave Chinner wrote:
> > On Mon, Jul 04, 2016 at 05:32:40AM +0000, Wang Shilong wrote:
> > > dd 16GB to /dev/shm/data to use memory backend storage to benchmark metadata performaces.
> 
> > I've never seen anyone create a ramdisk like that before.
> > What's the backing device type? i.e. what block device driver does
> > this use?
> 
> I guess you mean loop device here? It is common file and setup
> as loop0 device here.

For me, the "common" way to test a
filesystem with RAM backing it is to use the brd driver because it
can do DAX, is as light weight and scalable, and doesn't have any of
the quirks that the loop device has.

This is why I ask people to fully describe their hardware, software and
config - assumptions only lead to misunderstandings.

> > > Benchmark tool is mdtest, you can download it from
> > > https://sourceforge.net/projects/mdtest/
> >
> > What version? The sourceforge version, of the github fork that the
> > sourceforge page points to? Or the forked branch of recent
> > development in the github fork?
> 
> I don't think sourceforge version or github version make some
> differences here, you could use any of them.(I used Souceforge version)

They are different, and there's evidence of many nasty hacks in the
github version. it appears that some of them come from the source
forge version. Not particularly confidence inspiring.

> > > Steps to run benchmark
> > > #mkfs.xfs /dev/shm/data
> 
> > Output of this command so we can recreate the same filesystem
> > structure?
> 
> [root@localhost shm]# mkfs.xfs data
> meta-data=data                   isize=512    agcount=4, agsize=1025710 blks
>          =                       sectsz=512   attr=2, projid32bit=1
>          =                       crc=1        finobt=1, sparse=0
> data     =                       bsize=4096   blocks=4102840, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
> log      =internal log           bsize=4096   blocks=2560, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0

As I suspected, mkfs optimised the layout for the small size,
not performance. Performance will likely improve if you increase the
log size to something more reasonably sized for heavy metadata
workloads.

> > > #mount /dev/shm/data /mnt/test
> > > #mdtest -d /mnt/test -n 2000000
> > >
> > > 1 tasks, 2000000 files/directories
> > >
> > > SUMMARY: (of 1 iterations)
> > >    Operation                      Max            Min           Mean        Std Dev
> > >    ---------                      ---            ---           ----        -------
> > >    Directory creation:      24724.717      24724.717      24724.717          0.000
> > >    Directory stat    :    1156009.290    1156009.290    1156009.290          0.000
> > >    Directory removal :     103496.353     103496.353     103496.353          0.000
> > >    File creation     :      23094.444      23094.444      23094.444          0.000
> > >    File stat         :    1158704.969    1158704.969    1158704.969          0.000
> > >    File read         :     752731.595     752731.595     752731.595          0.000
> > >    File removal      :     105481.766     105481.766     105481.766          0.000
> > >    Tree creation     :       2229.827       2229.827       2229.827          0.000
> > >    Tree removal      :          1.275          1.275          1.275          0.000
> > >
> > > -- finished at 07/04/2016 12:54:26 --
> 
> > A table of numbers with no units or explanation as to what they
> > mean. Let me guess - I have to read the benchmark source code to
> > understand what the numbers mean?
> 
> You could look File Creation, Units mean number of files create per seconds.
> (Here it is 23094.444)

Great. What about all the others? How is the directory creation
number different to file creation? What about "tree creation"? What
is the difference between them - a tree implies multiple things are
being indexed, so that's got to be different in some way from file
and directory creation?

Indeed, if these are all measuring operations per second, then why
is tree creation 2000x faster than tree removal when file and
directory removal are 4x faster than creation? They can't all be
measuring single operations, and so the numbers are essentially
meaningless without being able to understand how they are different.

> > > IOPS for file creation is only 2.3W, however compare to Ext4 with same testing.
> 
> > Ummm - what unit of measurement is "W"? Watts?
> 
> Sorry, same as above..

So you made it up?

> > IOWs: Being CPU bound at 25,000 file creates/s is in line with
> > what I'd expect on XFS for a single threaded, single directory
> > create over 2 million directory entries with the default 4k
> > directory block size....
> ----------
> 
> I understand that this is single thread Limit, but I guess there are some
> other Limit here, because even single thread creating 50W files speed
> is twice than 200W files.

What's this W unit mean now? It's not 10000ops/s, like above,
because that just makes no sense at all.  Again: please stop
using shorthand or abbreviations that other people will not
understand. If you meant "the file  create speed is different when
creating 50,000 files versus creating 200,000 files", then write it
out in full because then everyone understands exactly what you mean.

/Assuming/ this is what you meant, then it's pretty obvious why they
are different - it's basic CS alogrithms and math. Answer these two
questions, and you have your answer as to what is going on:

	1. How does the CPU overhead of btree operation scale with
	increasing numbers of items in the btree?

	2. What does that do to the *average* insert rate for N
	insertions into an empty tree for increasing values of N?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bad Metadata performances for XFS?

[Chris Murphy]

On Mon, Jul 4, 2016 at 7:43 PM, Wang Shilong <wshilong@ddn.com> wrote:
>
>
> I understand that this is single thread Limit, but I guess there are some
> other Limit here, because even single thread creating 50W files speed
> is twice than 200W files.

Watts or Wolframs (tungsten)?

50W!=50000. You could write it as 50k and 200k. It's unlikely to get
confused with 50K and 200K, which are temperatures, because of
context. But W makes no sense.



-- 
Chris Murphy

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bad Metadata performances for XFS?

[Roger Willcocks]

On Tue, 2016-07-05 at 14:34 -0600, Chris Murphy wrote:
> On Mon, Jul 4, 2016 at 7:43 PM, Wang Shilong <wshilong@ddn.com> wrote:
> >
> >
> > I understand that this is single thread Limit, but I guess there are some
> > other Limit here, because even single thread creating 50W files speed
> > is twice than 200W files.
> 
> Watts or Wolframs (tungsten)?
> 
> 50W!=50000. You could write it as 50k and 200k. It's unlikely to get
> confused with 50K and 200K, which are temperatures, because of
> context. But W makes no sense.
> 
> 
> 

I suspect it's an abbreviation for the (Chinese) unit 'wan'

https://www.quora.com/Why-do-Chinese-people-count-in-units-of-10-000

so it makes perfect sense but it's not an SI unit.

--
Roger


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Bad Metadata performances for XFS?

[Dave Chinner]

On Wed, Jul 06, 2016 at 12:49:29PM +0100, Roger Willcocks wrote:
> On Tue, 2016-07-05 at 14:34 -0600, Chris Murphy wrote:
> > On Mon, Jul 4, 2016 at 7:43 PM, Wang Shilong <wshilong@ddn.com> wrote:
> > >
> > >
> > > I understand that this is single thread Limit, but I guess there are some
> > > other Limit here, because even single thread creating 50W files speed
> > > is twice than 200W files.
> > 
> > Watts or Wolframs (tungsten)?
> > 
> > 50W!=50000. You could write it as 50k and 200k. It's unlikely to get
> > confused with 50K and 200K, which are temperatures, because of
> > context. But W makes no sense.
> > 
> > 
> > 
> 
> I suspect it's an abbreviation for the (Chinese) unit 'wan'
> 
> https://www.quora.com/Why-do-Chinese-people-count-in-units-of-10-000
> 
> so it makes perfect sense but it's not an SI unit.

Thanks, Roger - it does make sense now the unit being used has been
explained. This is a canonical example of how being explicit about
units being used and what they mean is of prime importance to
understanding what each other are saying.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs